在切片中指定开始和结束旁边的开始和长度 [英] Specify start and length, beside start and end, in slices

查看:55
本文介绍了在切片中指定开始和结束旁边的开始和长度的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

你好,

很多时候我发现自己要求一个特定长度的片段,并且

写一些像l [12345:12345 + 10]。

这在交互式使用和编写Python程序时都会发生,

我必须写两次表达式(或使用临时变量)。


如果Python语法支持这个经常使用的
,那不是很好吗?我的想法是上面的表达式可能表示为

l [12345:> 10]。


据我所见,这个变化是非常小:它只影响

语法和字节编译,并且没有副作用。


语法的唯一变化是short_slice会被改变来自

[lower_bound]":" [upper_bound]

to

([lower_bound]":[upper_bound])| ([lower_bound]":>" [slice_length])


只是为了显示字节代码会发生什么:l [12345:12345 + 10]是

编译为:

LOAD_GLOBAL 0(l)

LOAD_CONST 1(12345)

LOAD_CONST 1(12345)

LOAD_CONST 2(10)

BINARY_ADD

SLICE + 3


我建议我[12345:> ; 10]将被编译为:

LOAD_GLOBAL 0(l)

LOAD_CONST 1(12345)

DUP_TOP

LOAD_CONST 2(10)

BINARY_ADD

SLICE + 3

嗯,您怎么看?我想听听你的意见。


祝你有个美好的一天(或夜晚),

Noam Raphael

解决方案

2004-05-21,Noam Raphael< no *** @ correctme.users.sourcephorge.net>写道:

很多时候我发现自己要求一个特定长度的片段,并且写了类似l [12345:12345 + 10]的内容。


[...]

如果Python语法支持这种频繁的使用,那不是很好吗?我的想法是,上面的表达式可能表示为[12345:> 10]。




它的效率有点低,但是你目前可以拼写为


l [12345:] [:10]


-

Grant Edwards grante佑!我们刚加入

民用头发巡逻!

visi.com


Grant Edwards写道:

2004-05-21,Noam Raphael< no *** @ correctme.users.sourcephorge.net>写道:

很多时候我发现自己要求一个特定长度的片段,并且写了类似l [12345:12345 + 10]的内容。



[...]

如果Python语法支持这种频繁的
使用?我的想法是上面的表达式可能表示为[12345:> 10]。



效率稍差,但你现在可以拼写作为

l [12345:] [:10]



这是真的,但是如果列表很长,它的效率会低很多* 。


感谢您的评论,

Noam


Noam Raphael写道:

格兰特爱德华兹写道:

它的效率有点低,但你现在可以拼写为

l [12345:] [: 10]


这是真的,但是如果列表很长,它的效率会低很多。




考虑到解释器特殊情况一些整数数学

包括BINARY_ADD,它可能不需要很长的列表

来传递它们相同的点。


从某种意义上说,我喜欢优化的想法,但我知道on''t

就像语法一样,怀疑是否有很多性能提升。

有。人们可能有更好的地方来攻击

翻译,而且不需要更改语法。


-Peter


Hello,
Many times I find myself asking for a slice of a specific length, and
writing something like l[12345:12345+10].
This happens both in interactive use and when writing Python programs,
where I have to write an expression twice (or use a temporary variable).

Wouldn''t it be nice if the Python grammar had supported this frequent
use? My idea is that the expression above might be expressed as
l[12345:>10].

This change, as far as I can see, is quite small: it affects only the
grammar and byte-compiling, and has no side effects.

The only change in syntax is that short_slice would be changed from
[lower_bound] ":" [upper_bound]
to
([lower_bound] ":" [upper_bound]) | ([lower_bound] ":>" [slice_length])

Just to show what will happen to the byte code: l[12345:12345+10] is
compiled to:
LOAD_GLOBAL 0 (l)
LOAD_CONST 1 (12345)
LOAD_CONST 1 (12345)
LOAD_CONST 2 (10)
BINARY_ADD
SLICE+3

I suggest that l[12345:>10] would be compiled to:
LOAD_GLOBAL 0 (l)
LOAD_CONST 1 (12345)
DUP_TOP
LOAD_CONST 2 (10)
BINARY_ADD
SLICE+3

Well, what do you think? I would like to hear your comments.

Have a good day (or night),
Noam Raphael

解决方案

On 2004-05-21, Noam Raphael <no***@correctme.users.sourcephorge.net> wrote:

Many times I find myself asking for a slice of a specific length, and
writing something like l[12345:12345+10].
[...]
Wouldn''t it be nice if the Python grammar had supported this frequent
use? My idea is that the expression above might be expressed as
l[12345:>10].



It''s a bit less efficient, but you can currently spell that as

l[12345:][:10]

--
Grant Edwards grante Yow! We just joined the
at civil hair patrol!
visi.com


Grant Edwards wrote:

On 2004-05-21, Noam Raphael <no***@correctme.users.sourcephorge.net> wrote:

Many times I find myself asking for a slice of a specific length, and
writing something like l[12345:12345+10].


[...]

Wouldn''t it be nice if the Python grammar had supported this frequent
use? My idea is that the expression above might be expressed as
l[12345:>10].


It''s a bit less efficient, but you can currently spell that as

l[12345:][:10]


That is true, but if the list is long, it''s *much* less efficient.

Thanks for your comment,
Noam


Noam Raphael wrote:

Grant Edwards wrote:

It''s a bit less efficient, but you can currently spell that as

l[12345:][:10]


That is true, but if the list is long, it''s *much* less efficient.



Considering that the interpreter special-cases some integer math
including the BINARY_ADD, it likely wouldn''t take a very long list
to pass the point where they''re the same.

I like the idea of the optimization, in a sense, but I don''t
like the syntax and doubt that there is much performance gain to be
had. There are probably better places for people to hack on the
interpreter, and which don''t need syntax changes.

-Peter


这篇关于在切片中指定开始和结束旁边的开始和长度的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆