Colin W. wrote:
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):
= r
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):
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 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.
y
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.
y
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 a
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 that
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 s
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 synt
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
> > 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
On Mon, 14 Dec 2009 18:40:38 -, Colin W.
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
Ugh. Magic characte
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 pyt
On Dec 14, 10: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 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 slice
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 go
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 sli
> 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 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 slice
http://www.python.org/dev/peps/pep-3003/
Geremy Condra
--
http://mail.python.org/mailman/listinfo/python-list
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 ":" betwe
22 matches
Mail list logo