[Python-ideas] Re: frozen dataclasses attribute initialization

On Thu, Dec 12, 2019 at 2:03 AM Eric V. Smith wrote: > On 12/11/2019 6:36 PM, Arthur Pastel wrote: > >> Add an extra hidden attribute to every instance just > >> to track whether you’re inside __post_init__ so __setattr__ can check > it? > I don't want to add attributes that weren't defined in th

[Python-ideas] Re: Argumenting in favor of first()

On Thu, Dec 12, 2019 at 10:22:33AM +0900, "Stephen J. Turnbull" wrote: > Greg Ewing writes: > > On 11/12/19 9:45 pm, Steven D'Aprano wrote: > > > But that's not what happens if you call `first(iterable)` multiple > > > times. Calling it once is fine, but people will call it multiple times. >

[Python-ideas] Re: Argumenting in favor of first()

> >take_one()? takeone()? take1()? > That could work. The docs can mention that for anything with ordering the result is guaranteed to be the *first* in the order. Do note that the main use case for the function is to consume only the first result of an iterable, generators in particular. In

[Python-ideas] Re: frozen dataclasses attribute initialization

On 12/12/2019 5:05 AM, Arthur Pastel wrote: On Thu, Dec 12, 2019 at 2:03 AM Eric V. Smith > wrote: On 12/11/2019 6:36 PM, Arthur Pastel wrote: >> Add an extra hidden attribute to every instance just >> to track whether you’re inside __post_init__ so __setat

[Python-ideas] Re: frozen dataclasses attribute initialization

> > On Thu, Dec 12, 2019 at 2:03 AM Eric V. Smith wrote: > >> On 12/11/2019 6:36 PM, Arthur Pastel wrote: >> >> Add an extra hidden attribute to every instance just >> >> to track whether you’re inside __post_init__ so __setattr__ can check >> it? >> I don't want to add attributes that weren't def

[Python-ideas] Python slicing

Python slicing looks really weird. How do I explain *s=list(range(100)); s[10:20] *gives you a part of the list. Can we have an extra function for lists and string (and wherever slicing works) to explicitly mention that we're slicing?? Something like - *s=list(range(100)); s.slice(10, 20).* Has t

[Python-ideas] Re: frozen dataclasses attribute initialization

On 12/12/2019 8:07 AM, Arthur Pastel wrote: On Thu, Dec 12, 2019 at 2:03 AM Eric V. Smith mailto:[email protected]>> wrote: On 12/11/2019 6:36 PM, Arthur Pastel wrote: >> Add an extra hidden attribute to every instance just >> to track whether you’re inside __post_

[Python-ideas] Re: frozen dataclasses attribute initialization

> > On 12/12/2019 8:07 AM, Arthur Pastel wrote: > > On Thu, Dec 12, 2019 at 2:03 AM Eric V. Smith wrote: >> >>> On 12/11/2019 6:36 PM, Arthur Pastel wrote: >>> >> Add an extra hidden attribute to every instance just >>> >> to track whether you’re inside __post_init__ so __setattr__ can check >>> i

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019, 7:28 AM Siddharth Prajosh wrote: > Something like - *s=list(range(100)); s.slice(10, 20).* > You mean like say s[slice(10,20)] ? Done. > > ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email t

[Python-ideas] Re: Python slicing

Hi Siddharth and Bruce The original poster asked for something like: >>> lst = list(range(100)) >>> lst.slice(10, 20) [10, 11, 12, 13, 14, 15, 16, 17, 18, 19] For what it's worth, I think such a thing could be useful. And that experience of it's use would be needed, before it could be added to P

[Python-ideas] Re: frozen dataclasses attribute initialization

On 12/12/2019 8:50 AM, Arthur Pastel wrote: On 12/12/2019 8:07 AM, Arthur Pastel wrote: On Thu, Dec 12, 2019 at 2:03 AM Eric V. Smith mailto:[email protected]>> wrote: On 12/11/2019 6:36 PM, Arthur Pastel wrote: >> Add an extra hidden attribute to

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019 at 04:17:58PM +0530, Siddharth Prajosh wrote: > Python slicing looks really weird. I disagree that it looks weird. I think it looks beautiful. > How do I explain *s=list(range(100)); > s[10:20] *gives you a part of the list. The same way that you explain that the ^ operat

[Python-ideas] Re: Python slicing

Hi Steve You wrote that we don't need a seq.slice(a, b) method, because the existing syntax does the job fine. To change the subject slightly, it seems to me that we don't need both seq[a:b] and slice(a, b). Certainly, we can get by without either. If we didn't have seq[a:b] we could use slice(a,

[Python-ideas] Re: Python slicing

On Dec 12, 2019, at 05:29, Siddharth Prajosh wrote: > > Python slicing looks really weird. How do I explain s=list(range(100)); > s[10:20] gives you a part of the list. Well, first you have to explain what “slicing” means, and that for lists it returns a new copy of the sub-list, and that it’

[Python-ideas] Re: Python slicing

On Dec 12, 2019, at 09:09, Jonathan Fine wrote: > > Finally, off-topic, I find it a bit odd that in the below we get syntax > errors (rather than a run-time error). > > >>> getslice[] > SyntaxError: invalid syntax > >>> getslice[1:2] > slice(1, 2, None) > >>> getslice[1:2:3] > slice(1, 2, 3) >

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019, at 12:31, Andrew Barnert via Python-ideas wrote: > > >>> getslice[] > > SyntaxError: invalid syntax > > What would you expect these to return? As an aside, I've occasionally wished that [] would be the same as [()], by analogy to [1,2].

[Python-ideas] Re: Python slicing

> As an aside, I've occasionally wished that [] would be the same as [()], > by analogy to [1,2]. > In that universe, would (),),),),) be the same as ()? ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to python

[Python-ideas] Re: Python slicing

> > >> As an aside, I've occasionally wished that [] would be the same as [()], >> by analogy to [1,2]. >> > > In that universe, would (),),),),) be the same as ()? > Sorry: I suppose what I meant was: () would be the same as (). ___ Pytho

[Python-ideas] Re: Argumenting in favor of first()

On Wed, Dec 11, 2019 at 9:48 PM Tim Peters wrote: > [Tim] > >> Every suggestion here so far has satisfied that, if S is a non-empty > set, > >> > >> assert next(iter(S)) is first(S) > >> > >> succeeds. That is, `first()` is _defined_ by reference to iteration > >> order. It's "the first" in

[Python-ideas] Re: Python slicing

On Dec 12, 2019, at 10:19, Ricky Teachey wrote: > >> >>> As an aside, I've occasionally wished that [] would be the same as [()], by >>> analogy to [1,2]. >> >> In that universe, would (),),),),) be the same as ()? > > Sorry: I suppose what I meant was: () would be the same as

[Python-ideas] Re: Argumenting in favor of first()

On Dec 12, 2019, at 10:34, Brett Cannon wrote: > > I'm also sure the docs will say "Returns the first item yielded by the > iterable." That last word is a dead give-away on how the choice will be made > on any collection, Sequence or not. 😉 (Doubly true if this goes into > itertools.) The doc

[Python-ideas] Re: Python slicing

> Sorry: I suppose what I meant was: () would be the same as (). > > > It already is the same: > > >>> () > () > > So presumably it would still be the same in that universe. :) > How embarrassing. > > I don’t see any problem with a[] being the same as a[()]. We already

[Python-ideas] Re: Python slicing

Hi Andrew (We're still a bit off-topic here.) You asked me what I'd expect, if not the present values of: >>> seq[] SyntaxError: invalid syntax >>> getslice[1:2:3:4] SyntaxError: invalid syntax I'd have expected to got respectively the outcome of >>> seq.__getitem__() >>> seq.__getitem__(sli

[Python-ideas] Re: Python slicing

On 2019-12-12 19:01, Andrew Barnert via Python-ideas wrote: On Dec 12, 2019, at 10:19, Ricky Teachey wrote: As an aside, I've occasionally wished that [] would be the same as [()], by analogy to [1,2].  In that universe, would (),),),),) be the same as ()?   Sorry:

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019 at 11:01:54AM -0800, Andrew Barnert via Python-ideas wrote: > I don’t see any problem with a[] being the same as a[()]. We already > have a[1,] is the same as a[(1,)] rather than a[1] A comma is not an "index argument seperator". a[1,] is not the same as a(1,) where the com

[Python-ideas] Re: Python slicing

On Dec 12, 2019, at 11:14, Ricky Teachey wrote: > > But what would happen if you call a user-defined class with a tuple as an > argument? > > class MyWeirdTuple(tuple): > def __new__(self, tup, *args): ... > > t = (1,2,3) > tuple(t) # returns (1,2,3) > MyWeirdTuple(t) # is t the first ar

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019 at 02:14:09PM -0500, Ricky Teachey wrote: > But what would happen if you call a user-defined class with a tuple as an > argument? > > class MyWeirdTuple(tuple): > def __new__(self, tup, *args): ... `__new__` is normally written with `cls` as the first argument, since it

[Python-ideas] Re: Python slicing

> > But what would happen if you call a user-defined class with a tuple as > an argument? > > > > class MyWeirdTuple(tuple): > > def __new__(self, tup, *args): ... > > > > t = (1,2,3) > > tuple(t) # returns (1,2,3) > > MyWeirdTuple(t) # is t the first argument, or is 1 the first argument? > >

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019, at 15:59, Steven D'Aprano wrote: > But why have the empty index default to () rather than None or 0 or -1 > or slice(None, None, None) or some other value? That's an arbitrary > and not a good one. My main reason for the suggestion was because that is the index used to acce

[Python-ideas] Re: Python slicing

> > tuple(t) isn't the same as tuple(1, 2, 3). Try it and see. > > > MyWeirdTuple(t) # is t the first argument, or is 1 the first argument? > > t is unambiguously the first argument. > I was responding to this sidebar, which was derailing the topic a bit and I apologize. And my response still d

[Python-ideas] Re: Python slicing

On 13/12/19 9:59 am, Steven D'Aprano wrote: So a[] would be: temp = # A syntax error. a[temp] not an empty tuple. That's the way it is now, but it doesn't have to be that way. There is some logic to the proposal. Currently the argument passed to __getitem__ is what you would get

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019 at 5:29 AM Siddharth Prajosh wrote: > Can we have an extra function for lists and string (and wherever slicing > works) to explicitly mention that we're slicing?? Something like - > *s=list(range(100)); > s.slice(10, 20).* > This exists already as ``itertools.islice`` and,

[Python-ideas] Re: Python slicing

On Dec 12, 2019, at 11:21, Jonathan Fine wrote: > > > (We're still a bit off-topic here.) You asked me what I'd expect, if not the > present values of: > > >>> seq[] > SyntaxError: invalid syntax > > >>> getslice[1:2:3:4] > SyntaxError: invalid syntax > > I'd have expected to got respectiv

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019 at 04:20:58PM -0500, Random832 wrote: > On Thu, Dec 12, 2019, at 15:59, Steven D'Aprano wrote: > > But why have the empty index default to () rather than None or 0 or -1 > > or slice(None, None, None) or some other value? That's an arbitrary > > and not a good one. > > My ma

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019 at 4:39 PM Steven D'Aprano wrote: > > Surely a zero-dimensional array ought to have no elements at all? > nope -- a zero-dimensional array is a scalar -- as distinct from a 1-d (or 2-d, or n-d) array that happens to have only one element. in fact, numpy has a confusing (at

[Python-ideas] Re: Python slicing

On Thu, Dec 12, 2019 at 7:39 PM Steven D'Aprano wrote: > Surely a zero-dimensional array ought to have no elements at all? > If you think of a 1-D array as falling on a line, and a 2-D array as occupying a region of a plane, then the equivalent of a geometric point is a 0-D array. It's not real

[Python-ideas] Re: Python slicing

We posted at same time. But the reason 0-D array isn't just a Python scalar is because it still has array attributes, most notably dtype. Now maybe 15 years ago NumPy could have created a bunch more custom numeric scalars for the different bit-lengths, but then we still wouldn't have the uniformit

[Python-ideas] Re: Python slicing

On Dec 12, 2019, at 16:40, Steven D'Aprano wrote: > > > Surely a zero-dimensional array ought to have no elements at all? Forgetting about the practical benefits of having a way to have scalars that have a dtype and respond to ndarray methods and so on, here’s how to convince yourself it make

[Python-ideas] Re: Argumenting in favor of first()

[Brett Cannon] > I'm also sure the docs will say "Returns the first item yielded by the iterable." That > last word is a dead give-away on how the choice will be made on any collection, > Sequence or not. (Doubly true if this goes into itertools.) > > There's also the contingency of users who will

[Python-ideas] Re: Argumenting in favor of first()

On Dec 12, 2019, at 20:51, Tim Peters wrote: > > BTW, you can go a long way in Python without knowing anything about `iter()` > or `next()`. But not without mastering `for` loops. That's why I prefer to > say that, for ordinary cases, > > a = first(it) > > has the same effect as: > >

[Python-ideas] Re: Argumenting in favor of first()

[Tim] >> BTW, you can go a long way in Python without knowing anything about `iter()` >> or `next()`. But not without mastering `for` loops. That's why I prefer to >> say that, for ordinary cases, >> >> a = first(it) >> >> has the same effect as: >> >> for a in it: >> break [Andr

[Python-ideas] Re: Argumenting in favor of first()

On Dec 12, 2019, at 21:52, Tim Peters wrote: > > I couldn't care less whether things are "obvious" at first - unless > they're Dutch ;-) Nothing about programming is obvious at first. > What I do care about is explanations that "stick" _after_ someone > makes the effort to learn them. Sure, but

[Python-ideas] Re: Argumenting in favor of first()

12.12.19 03:22, Stephen J. Turnbull пише: I would prefer that it not be implemented at all, but if it is implemented, its behavior should respect the intuition of the majority of those who want it, which seems to me to be "a variant of next() that doesn't raise and returns None by default on an e

[Python-ideas] Re: Argumenting in favor of first()

11.12.19 10:45, Steven D'Aprano пише: The thing is, we're fooled by the close similarity of iteration over iterators and other iterables (sequences and containers). Destructive iteration and non-destructive iteration is a big difference. Utility functions like the proposed `first` that try to pre