Re: [Python-ideas] How assignment should work with generators?

2017-11-28 0:52 GMT+03:00 Chris Angelico : > On Tue, Nov 28, 2017 at 8:49 AM, Guido van Rossum > wrote: > > My PEP queue for Python 3.7 is full though, so I would like to put this > off > > until 3.8. > > > > Yeah, I don't think this could reasonably be raced

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

Just a note : in typechecked code (such as mypy's source code) assert is used to guide the checker: assert isinstance(x, CallableType) return x.args # checker knows it's valid So the assert becomes a kind of type annotation. The runtime check helps during tests, but is not that important -

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 28.11.2017 8:59, Steven D'Aprano wrote: On Tue, Nov 28, 2017 at 07:35:45AM +0300, Ivan Pozdeev via Python-ideas wrote: Actually, the way I'm using them,     assert condition, "error message", type would probably be the most expressive way. I disagree that is expressive -- I call it

Re: [Python-ideas] How assignment should work with generators?

On Nov 28, 2017 12:32 AM, "Steven D'Aprano" wrote: On Tue, Nov 28, 2017 at 06:15:47PM +1300, Greg Ewing wrote: > Steven D'Aprano wrote: > >How does "stop iterating here" equate to a wildcard? > > The * means "I don't care what else the sequence has in it". > > Because I

Re: [Python-ideas] Using an appropriate tone in emails (was: Adding a thin wrapper class around the functions in stdlib.heapq)

On Mon, Nov 27, 2017 at 7:22 PM, bunslow wrote: > My first submission to this list was predicated on what I'd read in PEPs -- > and many of those, since they recommend major-enough changes to require a > PEP, have sections (often lengthy) dedicated to "what's wrong with the >

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 06:15:47PM +1300, Greg Ewing wrote: > Steven D'Aprano wrote: > >How does "stop iterating here" equate to a wildcard? > > The * means "I don't care what else the sequence has in it". > > Because I don't care, there's no need to iterate any further. I'll grant you that. But

Re: [Python-ideas] generator vs iterator etc. (was: How assignment should work with generators?)

On Tue, Nov 28, 2017 at 03:11:25PM +0900, Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > > The subset of iterators which are created as generators are *also* > > called generators, > > As long as we're being precise, I don't think that is precisely correct: > > >>> (x for x in

Re: [Python-ideas] How assignment should work with generators?

How about x, y ?= iterable with ?= being the lazy assignment operator? On Tue, Nov 28, 2017 at 9:45 AM, Steven D'Aprano wrote: > On Mon, Nov 27, 2017 at 06:31:28PM -0800, Mike Miller wrote: > > > Believe the question behind the idea was, how to grab a couple items and > >

Re: [Python-ideas] How assignment should work with generators?

On 27/11/2017 21:49, Guido van Rossum wrote: > On Mon, Nov 27, 2017 at 1:32 PM, Chris Angelico > wrote: > > On Tue, Nov 28, 2017 at 8:24 AM, Guido van Rossum > wrote: > > On Mon, Nov 27, 2017

Re: [Python-ideas] How assignment should work with generators?

On Mon, Nov 27, 2017 at 06:31:28PM -0800, Mike Miller wrote: > Believe the question behind the idea was, how to grab a couple items and > then *stop?* If the syntax route is chosen, I'd expect something that > tells me it is going to stop, like a "full stop" as the period/dot is > called in

Re: [Python-ideas] generator vs iterator etc. (was: How assignment should work with generators?)

Steven D'Aprano writes: > The subset of iterators which are created as generators are *also* > called generators, As long as we're being precise, I don't think that is precisely correct: >>> (x for x in range(1)) at 0x10dee5e08> >>> iter(range(1)) >>> iter((1,))

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On Tue, Nov 28, 2017 at 07:35:45AM +0300, Ivan Pozdeev via Python-ideas wrote: > Actually, the way I'm using them, > >     assert condition, "error message", type > > would probably be the most expressive way. I disagree that is expressive -- I call it *misleading*. I see something which

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On Tue, Nov 28, 2017 at 05:12:36AM +0300, Ivan Pozdeev via Python-ideas wrote: > The `assert' statment was created the same as in previous languages like > C/C++: a check to only do in debug mode, when you can't yet trust your > code to manage and pass around internal data correctly. That's not

Re: [Python-ideas] How assignment should work with generators?

Steven D'Aprano wrote: How does "stop iterating here" equate to a wildcard? The * means "I don't care what else the sequence has in it". Because I don't care, there's no need to iterate any further. -- Greg ___ Python-ideas mailing list

Re: [Python-ideas] How assignment should work with generators?

Kirill Balunov wrote: So someone too perlish clever can assume that with the proposed syntax: >>> def gen(): >>> for i in ['a', 'b', 'c', 'd']: >>> v = x if 'x' in globals() else 'var ' >>> yield v + i >>> x, y = gen() >>> x var a >>> y var ab There's no need for

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 28.11.2017 6:34, Ned Batchelder wrote: You are proposing:     assert condition, type, value Not specifically this, that's just an example. Actually, the way I'm using them,     assert condition, "error message", type would probably be the most expressive way. Why not just use Python

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 11/27/17 9:12 PM, Ivan Pozdeev via Python-ideas wrote: The `assert' statment was created the same as in previous languages like C/C++: a check to only do in debug mode, when you can't yet trust your code to manage and pass around internal data correctly. Examples are array bounds and object

Re: [Python-ideas] Using an appropriate tone in emails (was: Adding a thin wrapper class around the functions in stdlib.heapq)

On Mon, Nov 27, 2017 at 4:36 PM, Paul Moore wrote: > On 27 November 2017 at 21:59, Nick Timkovich > wrote: > > On Mon, Nov 27, 2017 at 8:17 PM, Brett Cannon wrote: > >> > >> But calling it "atrocious" and so bad that it needs to

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On Mon, Nov 27, 2017 at 9:28 PM, Ivan Pozdeev via Python-ideas < python-ideas@python.org> wrote: > On 28.11.2017 5:19, Chris Angelico wrote: > > Actually, Python does have a way of disabling assertions (the -O >> flag), so they should be treated the same way they are in C. >> Assertions should

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

> > Assertions should not be used as shorthands for "if cond: raise Exc" > in the general case. > I'm just a lurker and usually I agree with why the suggested features shouldn't be implemented, but I actually might chime in to pitch this one a bit more -- and I think it can be done nicely

Re: [Python-ideas] How assignment should work with generators?

Hmm, I didn't like the options below because they say to me, "consume everything:" x, y, * = iterable x, y, ... = iterable Believe the question behind the idea was, how to grab a couple items and then *stop?* If the syntax route is chosen, I'd expect something that tells me it is

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

On 28.11.2017 5:19, Chris Angelico wrote: Actually, Python does have a way of disabling assertions (the -O flag), so they should be treated the same way they are in C. Assertions should not be used as shorthands for "if cond: raise Exc" in the general case. I'm claiming, and provided evidence,

[Python-ideas] Repurpose `assert' into a general-purpose check

The `assert' statment was created the same as in previous languages like C/C++: a check to only do in debug mode, when you can't yet trust your code to manage and pass around internal data correctly. Examples are array bounds and object state integrity constraints. Unlike C, Python does the

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 10:49:45AM +1300, Greg Ewing wrote: > C Anthony Risinger wrote: > >* Perhaps existence of `__len__` should influence unpacking? There is a > >semantic difference (and typically a visual one too) between 1-to-1 > >matching a fixed-width sequence/container on the RHS to

Re: [Python-ideas] generator vs iterator etc. (was: How assignment should work with generators?)

On Mon, Nov 27, 2017 at 06:35:38PM +0200, Koos Zevenhoven wrote: > SOLUTION: Maybe (a) all iterators should be called iterators All iterators *are* called iterators. Just as all mammals are called "mammals". The subset of iterators which are created as generators are *also* called

Re: [Python-ideas] How assignment should work with generators?

Guido van Rossum wrote: Is this problem really important enough that it requires dedicated syntax? Isn't the itertools-based solution good enough? Well, it works, but it feels very clumsy. It's annoying to have to specify the number of items in two places. Also, it seems perverse to have to

Re: [Python-ideas] How assignment should work with generators?

27.11.17 23:24, Guido van Rossum пише: Is this problem really important enough that it requires dedicated syntax? Isn't the itertools-based solution good enough? (Or failing that, couldn't we add something to itertools to make it more readable rather than going straight to new syntax?) I

Re: [Python-ideas] How assignment should work with generators?

On 27 November 2017 at 21:54, Kirill Balunov wrote: > 2017-11-27 19:23 GMT+03:00 Paul Moore : > >> >> It should be reasonably easy >> to do a code search for something like "=.*islice", to find code >> that's a candidate for using the proposed syntax.

Re: [Python-ideas] How assignment should work with generators?

Guido van Rossum wrote: While it appears to rhyme with the use of a lone '*' in function signatures, it would actually mean the opposite: in signatures it means "don't allow any more". That's the usage that's out of step with the rest -- all the others can be seen as some form of wildcard.

Re: [Python-ideas] Using an appropriate tone in emails (was: Adding a thin wrapper class around the functions in stdlib.heapq)

On Mon, Nov 27, 2017 at 8:17 PM, Brett Cannon wrote: > But calling it "atrocious" and so bad that it needs to be fixed > "immediately" as if it's a blight upon the stdlib is unnecessarily > insulting to those that have worked on the module. To convey the feeling > that you

Re: [Python-ideas] How assignment should work with generators?

2017-11-27 19:23 GMT+03:00 Paul Moore : > It should be reasonably easy > to do a code search for something like "=.*islice", to find code > that's a candidate for using the proposed syntax. I suspect there's > very little code like that. While isclice is something

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 8:49 AM, Guido van Rossum wrote: > My PEP queue for Python 3.7 is full though, so I would like to put this off > until 3.8. > Yeah, I don't think this could reasonably be raced into 3.7 even if it were critically important, and it's not. 3.8 will be

Re: [Python-ideas] How assignment should work with generators?

C Anthony Risinger wrote: * Perhaps existence of `__len__` should influence unpacking? There is a semantic difference (and typically a visual one too) between 1-to-1 matching a fixed-width sequence/container on the RHS to identifiers on the LHS, even if they look similar (ie. "if RHS has a

Re: [Python-ideas] How assignment should work with generators?

While I was more optimistic when I proposed this idea, moving on I gradually become less and less optimistic. I did not underestimate how much this would change the semantics. At present, if the lhs is comma-separated list of targets, the rhs is evaluated, and only then if they match the

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 8:24 AM, Guido van Rossum wrote: > On Mon, Nov 27, 2017 at 1:18 PM, Greg Ewing > wrote: >> >> Chris Angelico wrote: >>> >>> The problem is that it depends on internal whitespace to >>> distinguish it from augmented

Re: [Python-ideas] How assignment should work with generators?

On Mon, Nov 27, 2017 at 1:13 PM, Greg Ewing wrote: > Chris Angelico wrote: > > x, y, * = iter # unpack into nothing >> > > I'm surprised this isn't already allowed. It seems like the > One Obvious Way to me. I'm not that surprised. While it appears to rhyme with

Re: [Python-ideas] How assignment should work with generators?

Chris Angelico wrote: The problem is that it depends on internal whitespace to distinguish it from augmented assignment; Ah, didn't spot that. I guess the ellipsis is the next best thing then. An alternative would be to require parens: (x, y, *) = z -- Greg

Re: [Python-ideas] How assignment should work with generators?

Chris Angelico wrote: x, y, * = iter # unpack into nothing I'm surprised this isn't already allowed. It seems like the One Obvious Way to me. -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Using an appropriate tone in emails (was: Adding a thin wrapper class around the functions in stdlib.heapq)

+1 Basically, if you're posting here, you probably want something to change. And that means that somebody has to make that change. And someone has to approve it. Etc. And you are trying to influence those people to make/approve/etc. that change, since for them it's less work if nothing change.

[Python-ideas] Using an appropriate tone in emails (was: Adding a thin wrapper class around the functions in stdlib.heapq)

On Tue, 21 Nov 2017 at 14:57 Nick Timkovich wrote: > On Tue, Nov 21, 2017 at 4:16 PM, Sven R. Kunze wrote: > >> Maybe, that suffices: https://pypi.python.org/pypi/xheap >> > I still think the heapq.heap* functions are atrocious and they should >

Re: [Python-ideas] How assignment should work with generators?

This proposal resonates with me. I've definitely wanted to use unpacking to crank an iterator a couple times and move on without exhausting the iterator. It's a very natural and intuitive meaning for unpacking as it relates to iterators. In my mind, this ask is aligned with, and has similar

[Python-ideas] generator vs iterator etc. (was: How assignment should work with generators?)

On Mon, Nov 27, 2017 at 3:55 PM, Steven D'Aprano wrote: > On Mon, Nov 27, 2017 at 12:17:31PM +0300, Kirill Balunov wrote: > ​​ > > > 2. Should this work only for generators or for any iterators? > > I don't understand why you are even considering singling out *only* >

Re: [Python-ideas] How assignment should work with generators?

On 27 November 2017 at 16:05, Chris Angelico wrote: > On Tue, Nov 28, 2017 at 2:35 AM, Steven D'Aprano wrote: >> In this case, there is a small but real benefit to counting the >> assignment targets and being explicit about the number of items to >> slice.

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 1:46 AM, Steven D'Aprano wrote: > On Tue, Nov 28, 2017 at 01:01:01AM +1100, Chris Angelico wrote: > >> And the status quo is noisy and has duplicated >> information (you have to match the ", 2" to the number of assignment >> targets). > > Er, not

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 01:14:40AM +1100, Chris Angelico wrote: > Nah, far easier: > > x, y = iter(it) > > since that'll be a no-op in the first case Not necessarily a no-op. __iter__ might have side-effects. Of course if you can guarantee that you ONLY have iterators, then there's no need

Re: [Python-ideas] How assignment should work with generators?

On Mon, Nov 27, 2017 at 4:50 PM, Kirill Balunov wrote: > > I really do not like to use "starred" targets in any way: > > x, y, * = iterable > ​This one won't work, because it looks like in-place multiplication (__imul__) which clashes with the above for a single name as

Re: [Python-ideas] How assignment should work with generators?

2017-11-27 17:14 GMT+03:00 Chris Angelico : > > > Nah, far easier: > > x, y = iter(it) > Yes, you are right. >> 2. Readable and not so verbose code > >> 3. Optimized case for x,y,*z = iterator > > > > The semantics of that are already set: the first two items are

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 01:01:01AM +1100, Chris Angelico wrote: > And the status quo is noisy and has duplicated > information (you have to match the ", 2" to the number of assignment > targets). Er, not really. How about: a, b = islice(iterable, 3, 10, 4) A somewhat unusual case, to be sure,

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 12:55 AM, Steven D'Aprano wrote: > But even if we decide on a simple rule like "iterator unpacking depends > on the number of targets, all other iterables don't", I think that will > be a bug magnet. It will mean that you can't rely on this special >

Re: [Python-ideas] How assignment should work with generators?

On Mon, Nov 27, 2017 at 03:31:38PM +0300, Kirill Balunov wrote: > As I can see at the moment, these cases should behave differently: > > >>> x, y = [1,2,3,4] # must raise ValueError > >>> x, y = iter([1,2,3,4]) # should work I *completely disagree* that they should behave

Re: [Python-ideas] How assignment should work with generators?

On Tue, Nov 28, 2017 at 12:44 AM, Daniel Moisset wrote: > On 27 November 2017 at 06:40, Chris Angelico wrote: >> >> Here are a few syntaxes that I believe have been proposed at various >> times: >> >> x, y = islice(iter, 2) # status quo >> x, y = iter #

Re: [Python-ideas] How assignment should work with generators?

On Mon, Nov 27, 2017 at 12:17:31PM +0300, Kirill Balunov wrote: > Currently during assignment, when target list is a comma-separated list of > targets (*without "starred" target*) the rule is that the object (rhs) must > be an iterable with the same number of items as there are targets in the >

Re: [Python-ideas] How assignment should work with generators?

On Mon, Nov 27, 2017 at 11:31 PM, Kirill Balunov wrote: > >> In terms of language proposals, you can't just say "don't need values >> for"; the semantics have to be EITHER "consume and discard" OR "don't >> consume". We already have a perfectly good way of spelling

Re: [Python-ideas] How assignment should work with generators?

2017-11-27 15:39 GMT+03:00 Paul Moore : > On 27 November 2017 at 12:31, Kirill Balunov > wrote: > > As I can see at the moment, these cases should behave differently: > > > x, y = [1,2,3,4] # must raise ValueError > x, y =

Re: [Python-ideas] How assignment should work with generators?

> In terms of language proposals, you can't just say "don't need values > for"; the semantics have to be EITHER "consume and discard" OR "don't > consume". We already have a perfectly good way of spelling "consume > and discard": > > x, y, _ = iter > You mean ( x, y, *_ = iter ) ? Since this has

Re: [Python-ideas] How assignment should work with generators?

On Mon, Nov 27, 2017 at 9:45 PM, Kirill Balunov wrote: > 2017-11-27 12:40 GMT+03:00 Chris Angelico : >> If you use "x, y, *z = gen1()", you'll trigger all the prints and >> completely consume the generator. With gen2(), you'll get an infinite >> loop.

Re: [Python-ideas] How assignment should work with generators?

On Mon, Nov 27, 2017 at 8:17 PM, Kirill Balunov wrote: > In many cases it is possible to do this right now, but in too verbose way: > x, y = islice(gen(), 2) > > But it seems for me that: > x, y = gen() > > Looks the same, easy to follow and not so verbose.