Re: [Python-ideas] Deterministic iterator cleanup

On Thu, Oct 20, 2016 at 11:03:11PM -0700, Nathaniel Smith wrote: > The motivation here is that prompt (non-GC-dependent) cleanup is a > good thing for a variety of reasons: determinism, portability across > Python implementations, proper exception propagation, etc. async does > add yet another ent

Re: [Python-ideas] Deterministic iterator cleanup

You know, I'm actually starting to lean towards this proposal and away from my earlier objections... On Wed, Oct 19, 2016 at 12:33:57PM -0700, Nathaniel Smith wrote: > I should also say, regarding your specific example, I guess it's an > open question whether we would want list_iterator.__itercl

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 07:03, Nathaniel Smith wrote: > Oh, goodness, no -- like Yury said, the use cases here are not > specific to async at all. I mean, none of the examples are async even > :-). [...] Ah I follow now. Sorry for the misunderstanding, I'd skimmed a bit more than I realised I had.

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 10:53, Steven D'Aprano wrote: > On Wed, Oct 19, 2016 at 12:33:57PM -0700, Nathaniel Smith wrote: > >> I should also say, regarding your specific example, I guess it's an >> open question whether we would want list_iterator.__iterclose__ to >> actually do anything. It could fl

Re: [Python-ideas] Deterministic iterator cleanup

On Wed, Oct 19, 2016 at 05:52:34PM -0400, Yury Selivanov wrote: > IOW I'm not convinced that if we implement your proposal we'll fix 90% > (or even 30%) of cases where non-deterministic and postponed cleanup is > harmful. Just because something doesn't solve ALL problems doesn't mean it isn't

Re: [Python-ideas] Deterministic iterator cleanup

On Fri, Oct 21, 2016 at 11:03:51AM +0100, Paul Moore wrote: > At the moment, the take home message for such users feels like it's > "you might need to scatter preserve() around your code, to avoid the > behaviour change described above, which you glazed over because it > talked about all that coro

Re: [Python-ideas] Deterministic iterator cleanup

On Fri, Oct 21, 2016 at 11:07:46AM +0100, Paul Moore wrote: > On 21 October 2016 at 10:53, Steven D'Aprano wrote: > > On Wed, Oct 19, 2016 at 12:33:57PM -0700, Nathaniel Smith wrote: > > > >> I should also say, regarding your specific example, I guess it's an > >> open question whether we would wa

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 12:23, Steven D'Aprano wrote: > On Fri, Oct 21, 2016 at 11:03:51AM +0100, Paul Moore wrote: > >> At the moment, the take home message for such users feels like it's >> "you might need to scatter preserve() around your code, to avoid the >> behaviour change described above, wh

Re: [Python-ideas] Civility on this mailing list

On 19 October 2016 at 21:29, Michel Desmoulin wrote: > +1. > > I read many disagreements, and people being rude and unprofessional on > occasions, but nothing that would make me have a bad day, even when I was > the target of it. > > I feel like people are really getting hyper sensitive about comm

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 21 October 2016 at 05:09, Random832 wrote: > On Tue, Oct 18, 2016, at 02:10, Nick Coghlan wrote: >> Hi, I contributed the current list comprehension implementation (when >> refactoring it for Python 3 to avoid leaking the iteration variable, >> as requested in PEP 3100 [1]), and "comprehensions

Re: [Python-ideas] Civility on this mailing list

On 21 October 2016 at 15:26, Nick Coghlan wrote: > - Remember that even if something we vehemently consider "wrong" makes > it into the reference implementation, the language does have a design > policy that allows us to correct design mistakes after a suitable > deprecation period, and we also ea

Re: [Python-ideas] Deterministic iterator cleanup

On 2016-10-21 6:29 AM, Steven D'Aprano wrote: On Wed, Oct 19, 2016 at 05:52:34PM -0400, Yury Selivanov wrote: [..] With you proposal, to achieve the same (and make the code compatible with new for-loop semantics), users will have to implement both __iterclose__ and __del__. As I ask above, c

Re: [Python-ideas] Deterministic iterator cleanup

On 2016-10-21 7:13 AM, Steven D'Aprano wrote: Consistency is over-rated, and we already have inconsistency here: file iterators behave differently from list iterators, because they can be closed: This is **very** arguable :) Yury ___ Python-ideas m

Re: [Python-ideas] Deterministic iterator cleanup

Personally, I hadn't realised we had this problem in asyncio until now. Does this problem happen in asyncio at all? Or does asyncio somehow work around it by making sure to always explicitly destroy the frames of all coroutine objects, as long as someone waits on each task? On 21 October 2016 at

Re: [Python-ideas] Civility on this mailing list

On 22 October 2016 at 01:07, Paul Moore wrote: > I wonder. Would there be value in adding a sign-up email to the list > (supported by a posting of that email to the list, to catch existing > contributors) that set out some of the basic principles of how changes > are judged for inclusion in Python

Re: [Python-ideas] Order of loops in list comprehension

On 21.10.2016 01:43, Greg Ewing wrote: Alexander Heger wrote: For me the current behaviour does not seem unreasonable as it resembles the order in which you write out loops outside a comprehension That's true, but the main reason for having comprehensions syntax in the first place is so that i

Re: [Python-ideas] Python multi-dimensional array constructor

On 19.10.2016 21:08, Todd wrote: a= [ 48, 11, 141, 13, -60, -37, 58, -52, -29, 134 || -6, 96, -66, 137, -59, -147, -118, -104, -123, -7 ||| -103, 50, -89, -12, 28, -12, 119, -131, -73, 21 || -58, 105, 25, -138, -106, -118, -29, -49, -63, -56 -43, -34, 101, -115

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 17.10.2016 23:53, Paul Moore wrote: On 17 October 2016 at 22:28, Mark Lawrence via Python-ideas wrote: How about changing https://wiki.python.org/moin/HowTo/Sorting ? Good point. Better still, https://docs.python.org/3.6/howto/sorting.html Don't know what the real difference between those

Re: [Python-ideas] Conditional Assignment in If Statement

On 18.10.2016 00:11, Michael duPont wrote: What does everyone think about: if foo = get_foo(): bar(foo) as a means to replace: foo = get_foo() if not foo: bar(foo) del foo Might there be some better syntax or a different keyword? I constantly run into this sort of use case. Befor

Re: [Python-ideas] please try to keep things civil

On 17/10/2016 19:29, Brett Cannon wrote: On Sun, 16 Oct 2016 at 09:39 Mark Lawrence via Python-ideas mailto:python-ideas@python.org>> wrote: On 16/10/2016 16:41, Mariatta Wijaya wrote: >>Her reaction was hilarious: >> >>"Whom does he teach? Children?" > > I sense mocker

Re: [Python-ideas] Deterministic iterator cleanup

Le 21/10/16 à 14:35, Paul Moore a écrit : [1] As I understand it. CPython's refcounting GC makes this a non-issue, correct? Wrong. Any guarantee that you think the CPython GC provides goes out of the window as soon as you have a reference cycle. Refcounting does not actually make GC determin

Re: [Python-ideas] please try to keep things civil

On 10/21/2016 12:13 PM, Mark Lawrence via Python-ideas wrote: This list is irrelevant. The PSF has to be consistent across all of its lists. This list is not irrelevant, and yes *volunteers who moderate* should be consistent. Who the hell is Marietta, I don't recall a single post from her

Re: [Python-ideas] please try to keep things civil

On 10/21/16 3:13 PM, Mark Lawrence via Python-ideas wrote: > On 17/10/2016 19:29, Brett Cannon wrote: >> >> >> On Sun, 16 Oct 2016 at 09:39 Mark Lawrence via Python-ideas >> > > wrote: >> >> On 16/10/2016 16:41, Mariatta Wijaya wrote: >> >>Her reaction was hi

Re: [Python-ideas] Deterministic iterator cleanup

On 2016-10-21 11:19 AM, Gustavo Carneiro wrote: Personally, I hadn't realised we had this problem in asyncio until now. Does this problem happen in asyncio at all? Or does asyncio somehow work around it by making sure to always explicitly destroy the frames of all coroutine objects, as long a

Re: [Python-ideas] Deterministic iterator cleanup

On Fri, Oct 21, 2016 at 12:12 AM, Steven D'Aprano wrote: > Portability across Pythons... if all Pythons performed exactly the same, > why would we need multiple implementations? The way I see it, > non-deterministic cleanup is the cost you pay for a non-reference > counting implementation, for th

Re: [Python-ideas] Python multi-dimensional array constructor

On 10/19/2016 12:08 PM, Todd wrote: At least in my opinion, this sort of approach really shines when making higher-dimensional arrays. These would all be equivalent (the | at the beginning and end are just to make it easier to align indentation, they aren't required): a = [ 48, 11, 141,

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 21:59, Chris Barker wrote: >> So (it seems to >> me) that you're talking about changing the behaviour of for-loops to >> suit only a small proportion of cases: maybe 10% of 10%. > > > I don't see what the big overhead is here. for loops would get a new > feature, but it would

Re: [Python-ideas] Deterministic iterator cleanup

NOTE: This is my first post to this mailing list, I'm not really sure how to post a message, so I'm attempting a reply-all. I like Nathaniel's idea for __iterclose__. I suggest the following changes to deal with a few of the complex issues he discussed. 1. Missing __iterclose__, or a valu

Re: [Python-ideas] Deterministic iterator cleanup

On 10/21/2016 03:48 PM, Amit Green wrote: NOTE: This is my first post to this mailing list, I'm not really sure how to post a message, so I'm attempting a reply-all. Seems to have worked! :) I like Nathaniel's idea for __iterclose__. I suggest the following changes to deal with a few

Re: [Python-ideas] Deterministic iterator cleanup

On Fri, Oct 21, 2016 at 3:48 PM, Amit Green wrote: > NOTE: This is my first post to this mailing list, I'm not really sure > how to post a message, so I'm attempting a reply-all. > > I like Nathaniel's idea for __iterclose__. > > I suggest the following changes to deal with a few of the comp

Re: [Python-ideas] Deterministic iterator cleanup

On Fri, Oct 21, 2016 at 3:29 AM, Steven D'Aprano wrote: > As for the amount of good, this proposal originally came from PyPy. Just to be clear, I'm not a PyPy dev, and the PyPy devs' contribution here was mostly to look over a draft I circulated and to agree that it seemed like something that'd b

[Python-ideas] Smart/Curly Quote Marks and cPython

Hello everyone, I want to start small and ask about smart/curly quote marks (” vs "). Although most languages do not support these characters as quotation marks, I believe that cPython should, if possible. I'm willing to write the patch, of course, but I wanted to ask about this change, if it has

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

On 10/21/2016 10:17 PM, Ryan Birmingham wrote: I want to start small and ask about smart/curly quote marks (” vs "). Although most languages do not support these characters as quotation marks, I believe that cPython should, if possible. I'm willing to write the patch, of course, but I wanted

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

I was thinking of using them only as possibly quotes characters, as students and beginners seem to have difficulties due to this quote-mismatch error. That OSX has smart quotes enabled by default makes this a worthwhile consideration, in my opinion. -Ryan Birmingham On 22 October 2016 at 01:34, E

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

Interesting idea. +1 from me; probably can be as simple as just having the tokenizer interpret curly quotes as the ASCII (straight) version of itself (in other words, " and the two curly versions of that would all produce the same token, and same for single quotes, eliminating any need for addition

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

On Sat, Oct 22, 2016 at 01:17:58AM -0400, Ryan Birmingham wrote: > Hello everyone, > > I want to start small and ask about smart/curly quote marks (” vs "). Which curly quotes are you going to support? There's Dutch, of course: „…” ‚…’ But how about … ? - English ‘…’ “…” - French « … » “…” -

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

The quotes I intended in this email are just “ ‘ ” , and ’ where the encoding is appropriate. Internationalization was not the intent of this. I do believe that you have a good point with supporting common quotes in other languages, but I believe that such a change would be large enough to consider