Prev: What is the differences between tkinter in windows and Tkinter in the other platform?
Next: multiprocessing callbacks?
From: Terry Reedy on 14 Dec 2009 14:24
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 good
reason. Absent that, I would not mind if the syntax remains frozen for
the rest of 3.x. A minor abbreviation that makes the language look more
like Perl will not cut it.

Terry Jan Reedy

From: Lie Ryan on 14 Dec 2009 14:41
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 notation would
> require one ":" between the brackets to differentiate it from a list,
> which is similar to the set notation requirement that disambiguates it
> from a dictionary.

I would prefer [a: b, ...] syntax to become an ordered dictionary
literal (if it would ever gain traction).
From: Steven D'Aprano on 14 Dec 2009 16:22
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 change, knowing that there's no way it
could be added to the language, and when the Python moratorium ends the
discussion will just happen all over again.


--
Steven
From: Carl Banks on 14 Dec 2009 16:23
On Dec 14, 10:03 am, Dave <b49P23T...(a)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 python user.  The slice notation would
> require one ":" between the brackets to differentiate it from a list,
> which is similar to the set notation requirement that disambiguates it
> from a dictionary.
>
> Several times now I've wanted python slice notation.  Perhaps I'll
> write a Python Enhancement Proposal.  I stored slices of vector array
> entries to add
>
> edge = 4
> indexes = []
> n = edge
> nn = n**2
> for i in range(edge):
>     indexes.extend([
>         slice(i*n,(i+1)*n,1),       # rows
>         slice(i,nn,n),              # cols
>         ])
>
> row_slices = indexes[0::2]
> col_slices = indexes[1::2]
> slash = slice(n-1,n*(n-1)+1,n-1)
> backslash = slice(0,nn,n+1)
>
> Which could have been written in a manner completely consistent with
> other python shorthand notations and for which python "cannot
> possibly" use the notation for some other purpose,
>
> edge = 4
> indexes = []
> n = edge
> nn = n**2
> for i in range(edge):
>     indexes.extend([
>         [i*n: (i+1)*n]                  # rows
>         [i: nn: n],                      # cols
>         ])
>
> row_slices = indexes[0::2]
> col_slices = indexes[1::2]
> slash = [n-1: n*(n-1)+1: n-1]
> backslash = [0: nn: n+1]

-1

Explicit creation of slice objects is an uncommon need and there is no
reason to support it with its own syntax.

I'd agree with Terry Reedy that range/xrange is far more commonly used
than slice objects, and if a floating slice syntax were ever added to
Python it ought to be used for range.


If you need to use a lot of slice objects you can lower your code
footprint by defining a helper class like this (adapt as needed):

class SliceCreator(object):
def __getitem__(self,loc):
if not isinstance(loc,slice):
raise TypeError
return loc
slc = SliceCreator()

slash = slc[n-1: n*(n-1)+1: n-1]


It might have been a reasonable idea for slice (and, perhaps, range)
to use slice notation rather than a function call, on the thinking
that the notational convenience outweighs the fact that you're not
actually getting an item, but it's too late for that.


Carl Banks
From: Nobody on 14 Dec 2009 16:45
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 user. The slice notation would
> require one ":" between the brackets to differentiate it from a list,
> which is similar to the set notation requirement that disambiguates it
> from a dictionary.
>
> Several times now I've wanted python slice notation. Perhaps I'll
> write a Python Enhancement Proposal.

Would it suffice to add the equivalent of numpy.s_ as a builtin?

> 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__?

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: What is the differences between tkinter in windows and Tkinter in the other platform?
Next: multiprocessing callbacks?