On 18-Dec-09 23:16 PM, Nobody wrote:
On Fri, 18 Dec 2009 09:49:26 -0500, Colin W. wrote:
You don't say, but seem to imply that the slice components include None.
That's how missing components are implemented at the language level:
class foo:
= def __getitem__(self, s):
Colin W. wrote:
div class=moz-text-flowed style=font-family: -moz-fixedOn
18-Dec-09 23:16 PM, Nobody wrote:
On Fri, 18 Dec 2009 09:49:26 -0500, Colin W. wrote:
You don't say, but seem to imply that the slice components include
None.
That's how missing components are implemented at the
On 17-Dec-09 20:00 PM, Nobody wrote:
On Mon, 14 Dec 2009 14:18:49 -0500, Terry Reedy wrote:
Many more people uses range objects (xrange in 2.x). A range object has
the same info as a slice object *plus* it is iterable.
This isn't quite true, as a range cannot have a stop value of None, i.e.
On 17-Dec-09 20:00 PM, Nobody wrote:
On Mon, 14 Dec 2009 14:18:49 -0500, Terry Reedy wrote:
Many more people uses range objects (xrange in 2.x). A range object has
the same info as a slice object *plus* it is iterable.
This isn't quite true, as a range cannot have a stop value of None, i.e.
On Fri, 18 Dec 2009 09:49:26 -0500, Colin W. wrote:
You don't say, but seem to imply that the slice components include None.
That's how missing components are implemented at the language level:
class foo:
= def __getitem__(self, s):
= return s
=
On Mon, 14 Dec 2009 14:18:49 -0500, Terry Reedy wrote:
Many more people uses range objects (xrange in 2.x). A range object has
the same info as a slice object *plus* it is iterable.
This isn't quite true, as a range cannot have a stop value of None, i.e.
you can't represent [n:] or [:] etc as
Terry Reedy wrote:
So it would be
MUCH more useful if that notation created a range object.
for i in [1:n]: ...
So I would oppose the slice proposal in favor of a range proposal.
Another possibility would be to unify range and slice
objects so that they're actually the same thing. Then
the
On 16-Dec-09 19:23 PM, Gregory Ewing wrote:
Terry Reedy wrote:
So it would be MUCH more useful if that notation created a range object.
for i in [1:n]: ...
So I would oppose the slice proposal in favor of a range proposal.
Another possibility would be to unify range and slice
objects so
from numpy import s_
s_[1:2:3]
slice(1, 2, 3)
s_[1:2:3, ..., 4:5]
(slice(1, 2, 3), Ellipsis, slice(4, 5, None))
Or would it be possible to define slice itself so that it implements
__getitem__ and __getslice__?
Indeed!
Python 2.6.4 (r264:75706,
Steven D'Aprano:
I've lost all enthusiasm for discussing language enhancements
That's probably the main downside of the moratorium. Humans need to
play some to keep their will to work and improve things.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Terry Reedy wrote:
On 12/14/2009 1:10 PM, geremy condra wrote:
http://www.python.org/dev/peps/pep-3003/
The moratorium does not stop proposals for things to be added after the
moratorium ends. But it does show that Guido and the devs are reluctant
to make *any* change to the core syntax of
Just as sets may now be written as {3,'hi'}, I propose that slices
should be available using [start:end] syntax. Following example comes
from projecteuler.net problem 166. The Numeric community would also
like this, as would the general python user. The slice notation would
require one :
http://www.python.org/dev/peps/pep-3003/
Geremy Condra
--
http://mail.python.org/mailman/listinfo/python-list
On 14-Dec-09 13:03 PM, Dave wrote:
Just as sets may now be written as {3,'hi'}, I propose that slices
should be available using [start:end] syntax. Following example comes
from projecteuler.net problem 166. The Numeric community would also
like this, as would the general python user. The
Yes, we know that PEP 3003 applies but I see no harm in discussing possible
enhancements.
I don't think the OP knew that the moratorium was in effect. That's why I
brought it up.
Geremy Condra
--
http://mail.python.org/mailman/listinfo/python-list
On 12/14/2009 1:03 PM, Dave wrote:
Just as sets may now be written as {3,'hi'}, I propose that slices
should be available using [start:end] syntax.
I believe this has been proposed and rejected on one of the py-dev,
py-ideas, or py-3k lists, but I would have to check to be sure.
Extended
On 12/14/2009 1:10 PM, geremy condra wrote:
http://www.python.org/dev/peps/pep-3003/
The moratorium does not stop proposals for things to be added after the
moratorium ends. But it does show that Guido and the devs are reluctant
to make *any* change to the core syntax of 3.x without really
On 12/15/2009 5:03 AM, Dave wrote:
Just as sets may now be written as {3,'hi'}, I propose that slices
should be available using [start:end] syntax. Following example comes
from projecteuler.net problem 166. The Numeric community would also
like this, as would the general python user. The
On Mon, 14 Dec 2009 13:40:38 -0500, Colin W. wrote:
Yes, we know that PEP 3003 applies but I see no harm in discussing
possible enhancements.
You bored? Looking for something to do?
I've lost all enthusiasm for discussing language enhancements, regardless
of whether I'm for or against the
On Dec 14, 10:03 am, Dave b49p23t...@stny.rr.com wrote:
Just as sets may now be written as {3,'hi'}, I propose that slices
should be available using [start:end] syntax. Following example comes
from projecteuler.net problem 166. The Numeric community would also
like this, as would the general
On Mon, 14 Dec 2009 10:03:16 -0800, Dave wrote:
Just as sets may now be written as {3,'hi'}, I propose that slices
should be available using [start:end] syntax. Following example comes
from projecteuler.net problem 166. The Numeric community would also
like this, as would the general python
On Mon, 14 Dec 2009 18:40:38 -, Colin W. cjwilliam...@gmail.com
wrote:
If your scheme flies, would it be practicable to use the same syntax
as a range generator?
range(i, j, k) = i:j:k
so range(10, 2) = :10:2
i.e. we could write for i in :10:2:
or the more common:
range(10) = :10
22 matches
Mail list logo
