Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 4/21/2014 1:39 AM, Nick Coghlan wrote: OK, I've now updated the PEP to better described the *problem* (rather than skipping ahead to proposing a specific solution - exactly what I was asking people *not* to do at the language summit!), Looks great. I think the analysis should be part of a dict section of the porting how-to. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Hi Nick, On 21 April 2014 07:39, Nick Coghlan ncogh...@gmail.com wrote: Notably, I recommend that hybrid code avoid calling mapping iteration methods directly, and instead rely on builtin functions where possible, and some additional helper functions for cases that would be a simple combination of a builtin and a mapping method in pure Python 3 code, but need to be handled slightly differently to get the exact same semantics in Python 2. How about explicitly noting that in Python 2, a large fraction of usages of the iterkeys(), itervalues() and iteritems() methods (that's more than 99% in my experience, but I might be biased) should just be written as keys(), values() and items() in the first place, with no measurable difference of performance or memory usage? I would recommend to anyone with a large Python 2 code base to simply do a textual search-and-replace and see if any test breaks. If not, problem solved. A bientôt, Armin. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 04/20/2014 10:39 PM, Nick Coghlan wrote: Lists as mutable snapshots -- [...] The semantic equivalent of these operations in Python 3 are ``list(d.keys())``, ``list(d.values())`` and ``list(d.iteritems())``. Last item should be ``list(d.items())``. Iterator objects [...] In Python 3, direct iteration over mappings works the same way as it does in Python 2. There are no method based equivalents - the semantic equivalents of ``d.itervalues()`` and ``d.iteritems()`` in Python 3 are ``iter(d.values())`` and ``iter(d.iteritems())``. ``iter(d.items())``. Thanks again, Nick. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
-Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Steven D'Aprano If this is a cunning plan to make Nick's suggestion sound better by suggesting an even worse alternative, it's working :-) You got me. However, I also admit to having learned something today from the PEP. That 2to3 actually replaces d.iteritems() with iter(d.items()). In all my porting experience this conservative approach is redundant for my use cases which is usally just immediate iteration, so I have successfully replaced d.iteritems() with d.items() without issue. For polyglot code, with rare exceptions simply using d.items() in both places is good enough, since IMHO the ill effects of creating temporary list objects is somewhat overstated. The PEP however explicitly wants to do it correctly because testing is often limited. So I withdraw my suggestion :) K ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Hi Guys, please don't do it! We don't need this legacy really. On 21 April 2014 08:41, Armin Rigo ar...@tunes.org wrote: Hi Nick, On 21 April 2014 07:39, Nick Coghlan ncogh...@gmail.com wrote: Notably, I recommend that hybrid code avoid calling mapping iteration methods directly, and instead rely on builtin functions where possible, and some additional helper functions for cases that would be a simple combination of a builtin and a mapping method in pure Python 3 code, but need to be handled slightly differently to get the exact same semantics in Python 2. How about explicitly noting that in Python 2, a large fraction of usages of the iterkeys(), itervalues() and iteritems() methods (that's more than 99% in my experience, but I might be biased) should just be written as keys(), values() and items() in the first place, with no measurable difference of performance or memory usage? I would recommend to anyone with a large Python 2 code base to simply do a textual search-and-replace and see if any test breaks. If not, problem solved. Couldn't agree more with Armin. -- http://lucasbardella.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
-Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Armin Rigo Sent: 21. apríl 2014 07:42 To: Nick Coghlan Cc: Python-Dev Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods How about explicitly noting that in Python 2, a large fraction of usages of the iterkeys(), itervalues() and iteritems() methods (that's more than 99% in my experience, but I might be biased) should just be written as keys(), values() and items() in the first place, with no measurable difference of performance or memory usage? I would recommend to anyone with a large Python 2 code base to simply do a textual search-and-replace and see if any test breaks. If not, problem solved. +1 K ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 20 April 2014 03:49, Steven D'Aprano st...@pearwood.info wrote: I don't believe that will happen, the line *will* be drawn somewhere, before Python 3 dies a death of a thousand cuts. I think that the right place to draw the line is *here*, not the next time, or the time after that. I think that the decision should be made on technical reasons, not so people feel that they are being listened to. I agree. I think that it's right that we should listen to users' frustrations with the (deliberately) backward incompatible changes. But listening does not imply not questioning. It's perfectly fair and reasonable to say We understand that you feel there is an overhead here - we tried very hard to design Python 3 with future benefits in mind, and we assessed the costs as best we could given the data we had available. Could you please provide some quantitative data on how the loss of iterXXX affects you, with specific code details, so that we can review what you believe you have to do and consider whether you have missed an approach we were expecting projects to take, or whether your figures imply that we seriously underestimated the cost. We can then consider how best to address the implications of the information you provide. Ultimately, every time we add *any* sort of compatibility feature to Python 3 (Unicode literals, bytes interpolation, this) we are sending the message that we made a mistake in the design of Python 3. It's certainly possible that's the case (we didn't have a lot of hard data to go on) but I do think we should have a little more confidence in our judgement here. As Steven said, there are a *lot* of people happy with Python 3. They don't say much, precisely because they are happy - that's the point. Let's not fall foul of the mistake of only listening to people who complain. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, Apr 19, 2014 at 02:25:53PM +1000, Steven D'Aprano wrote: In my experience, writing polyglot 2+3 code can be easily handled with a few helper functions, which is not the case with unicode string literals. (Non-polygot code of course can just use the methods directly.) I don't see this is a problem to be solved, or even much of a nuisance. Polyglot code is never going to be quite as straightforward or idiomic as non-polyglot code, and that's a good thing, as it reminds the reader that they are dealing with polyglot code. The problem i currently see is that most polyglot-projects are reimplementing the same helper functions (for dict access, literals wrapping etc), not depending on six because the authors don't feel it's worth the extra dependency, as they never need the full functionality of six. So how about including a subset of six' more popular functionality into the standard libraries of Python 2 and 3? I think it would solve the problem i described (i.e. remove boilerplate for polyglot code), while it would also avoid compromising the builtins of Python 3 (and keep polyglot code explicitly ugly) Also, that's why people demanded a Python 2.8... so that you don't have to pollute Python 3 instead. -- Markus ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 20/04/2014 06:31, Ethan Furman wrote: Thank you for taking the time to write this up, Nick. However, I am -1 on it. One of the allures of Python 3 is the increase in simplicity and elegance. Restoring cruft does not help with that. Python 2 idioms that get restored to Python 3 must have real value: unicode literals, wire-protocol interpolations -- I don't feel that this comes any where close to meeting that bar. -- ~Ethan~ +1 for this summary which echoes my sentiments entirely. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 20 Apr 2014 08:14, Markus Unterwaditzer mar...@unterwaditzer.net wrote: Also, that's why people demanded a Python 2.8... so that you don't have to pollute Python 3 instead. It doesn't actually solve the problem in the library and framework cases though - most folks that are straddling 2/3 want to keep compatibility back to at least 2.6. That said, I think we've covered most of what can be discussed based on this initial iteration of the PEP. To advance the discussion further I need to do a new draft that: - quantifies the scale of the change to the dict API and covers ideas for mitigating that impact (like immediate deprecation and potentially even hiding them from dir(), or adding proper function and method deprecation support to pydoc) - quantifies the number of lines of Python 2 code potentially saved near term modification, or, if they have added Python 3 support already, the amount of work that *could* have been saved (I'm not a big enough fan of the proposal to do that work myself, though - if the folks requesting the change aren't sufficiently interested to consider it worth their while to quantify the direct benefits even deprecated methods could have saved them, I consider that a data point in its own right) - explicitly covers all the different ways methods that produce iterators can be operated on, and how those need to be handled differently when migrating to the common subset of Python 2 3 rather than directly to 3. Regards, Nick. -- Markus ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/2014 07:37 AM, Paul Moore wrote: Ultimately, every time we add *any* sort of compatibility feature to Python 3 (Unicode literals, bytes interpolation, this) we are sending the message that we made a mistake in the design of Python 3. It's certainly possible that's the case (we didn't have a lot of hard data to go on) but I do think we should have a little more confidence in our judgement here. We clearly made mistakes, especially in how we thought migration would occur: nobody expected that we would see straddling / compatible subset as the dominant porting strategy. Re-adding features to make the strategy that works less painful is just acknowledging that fact. Mark such features as BBB-only / deprecated-but-never-to-be-removed, and move on: practicality beats purity. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNT4gcACgkQ+gerLs4ltQ4a3wCfcKZWldlrPzNn6byYJrCxm1XG ttUAniKTQ6ma0n7XNIMf0lP4A1zexT6j =AkQ+ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote: Does one ever use iteritems() et al without first invoking iter() on it? I can't speak for others, but I never invoke iteritems *with* iter(). What would be the point? iteritems is documented as returning an interator. # never this for key, value in iter(mydict.iteritems()): ... # but this for key, value in mydict.iteritems(): ... I.e. is it important that it is an iterator, rather than an iterable? I think we could easily relax that requirement in the pep and solve 99% of the use cases. And the other 1% of cases would be a land-mine waiting to blow the user's code up. Would it actually solve 99% of the use cases? Or only 90%? Or 50%? How do you know? In Python 2.7 iteritems() etc is documented as returning an iterator. That's a promise of the language, and people will rely on it. But they won't be able to rely on that promise in polygot 2+3 code -- exactly the use-case this PEP is trying to satisfy -- because the promise to return an iterator will be broken in 3. It would be actively misleading, since Python 3's iteritems() would return a view, not an iter, and it would fail at solving the backwards compatibility issue since views and iterators are not interchangeable except for the most basic use of iteration. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
-Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Eric Snow Sent: 19. apríl 2014 23:15 To: Barry Warsaw Cc: Python-Dev Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods I agree. I've been trying to get rid of iter*() when porting because most of the time, there is no significant memory savings to be achieved anyway. While I also have the gut feeling that we have been placing too much value in the memory savings of iteritems() vs iter(), the approach of just using iter() has the problem that it is semantically different. Compatible source code would have to use list(mydict.items()) to have the same meaning in 2 and 3. And then we are starting to feel pain again. K ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Well, for i in x and other iteration constructs already call iter () on their iterable. That's the point. Unless you want to manually iterate using next () then the distinction between an iterable and an iterator is academic. Sent from the æther. Original message From: Steven D'Aprano Date:20/04/2014 17:05 (GMT+00:00) To: python-dev@python.org Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote: Does one ever use iteritems() et al without first invoking iter() on it? I can't speak for others, but I never invoke iteritems *with* iter(). What would be the point? iteritems is documented as returning an interator. # never this for key, value in iter(mydict.iteritems()): ... # but this for key, value in mydict.iteritems(): ... I.e. is it important that it is an iterator, rather than an iterable? I think we could easily relax that requirement in the pep and solve 99% of the use cases. And the other 1% of cases would be a land-mine waiting to blow the user's code up. Would it actually solve 99% of the use cases? Or only 90%? Or 50%? How do you know? In Python 2.7 iteritems() etc is documented as returning an iterator. That's a promise of the language, and people will rely on it. But they won't be able to rely on that promise in polygot 2+3 code -- exactly the use-case this PEP is trying to satisfy -- because the promise to return an iterator will be broken in 3. It would be actively misleading, since Python 3's iteritems() would return a view, not an iter, and it would fail at solving the backwards compatibility issue since views and iterators are not interchangeable except for the most basic use of iteration. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
-Original Message-
From: Python-Dev [mailto:python-dev-
bounces+kristjan=ccpgames@python.org] On Behalf Of Steven
On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote:
Wouldn't iterkeys simply be an alias for keys and so on?
I'm +1 on that.
No.
[steve@ando ~]$ python2.7 -c it = {}.iterkeys(); print it is iter(it)
True
[steve@ando ~]$ python3.3 -c it = {}.keys(); print(it is iter(it))
False
Does one ever use iteritems() et al without first invoking iter() on it? I.e.
is it important that it is an iterator, rather than an iterable?
I think we could easily relax that requirement in the pep and solve 99% of the
use cases.
K
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sun, Apr 20, 2014 at 12:27 PM, Kristján Valur Jónsson krist...@ccpgames.com wrote: Well, for i in x and other iteration constructs already call iter () on their iterable. That's the point. Unless you want to manually iterate using next () then the distinction between an iterable and an iterator is academic. Or unless you iterate over the same thing multiple times, which can happen. P.S.: If Python had intended to support 2.x/3.x polyglots in the first place, would iteritems etc. have been removed? My feeling is no, in which case they should be re-added, since this is the main supported porting mechanism going forward. -- Devin Original message From: Steven D'Aprano Date:20/04/2014 17:05 (GMT+00:00) To: python-dev@python.org Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote: Does one ever use iteritems() et al without first invoking iter() on it? I can't speak for others, but I never invoke iteritems *with* iter(). What would be the point? iteritems is documented as returning an interator. # never this for key, value in iter(mydict.iteritems()): ... # but this for key, value in mydict.iteritems(): ... I.e. is it important that it is an iterator, rather than an iterable? I think we could easily relax that requirement in the pep and solve 99% of the use cases. And the other 1% of cases would be a land-mine waiting to blow the user's code up. Would it actually solve 99% of the use cases? Or only 90%? Or 50%? How do you know? In Python 2.7 iteritems() etc is documented as returning an iterator. That's a promise of the language, and people will rely on it. But they won't be able to rely on that promise in polygot 2+3 code -- exactly the use-case this PEP is trying to satisfy -- because the promise to return an iterator will be broken in 3. It would be actively misleading, since Python 3's iteritems() would return a view, not an iter, and it would fail at solving the backwards compatibility issue since views and iterators are not interchangeable except for the most basic use of iteration. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/jeanpierreda%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sun, Apr 20, 2014 at 07:27:08PM +, Kristján Valur Jónsson wrote: Well, for i in x and other iteration constructs already call iter () on their iterable. That's the point. Unless you want to manually iterate using next () then the distinction between an iterable and an iterator is academic. Do you think that for loops are the only way that iteritems and friends get used? You can't know that. I know from my own code that it isn't true. Iterators are first class objects like any other object, and they get put into tuples, passed around as arguments to functions, stored in variables, and so on. They get tested to be iterators, e.g.: assert the_items is iter(the_items) and, yes, sometimes people call next() on them directly. There is a reason that viewitems() etc. were added to Python 2.7 rather than just changing iteritems() to return a view. It would break backward compatibility, and break people's code. How much code? I don't know, but *any* breakage defeats the purpose of this suggestion. The whole point of this PEP is for the iter* methods to work the same way in Python 2 and Python 3, not nearly the same, sorry if it breaks your code. If we wanted nearly the same, we already have that: dict.items() in Python 2 and 3 is already nearly the same, they are both iterable. Nearly the same is not good enough. If this is a cunning plan to make Nick's suggestion sound better by suggesting an even worse alternative, it's working :-) -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 20Apr2014 14:32, Mark Lawrence breamore...@yahoo.co.uk wrote: On 20/04/2014 06:31, Ethan Furman wrote: Thank you for taking the time to write this up, Nick. However, I am -1 on it. One of the allures of Python 3 is the increase in simplicity and elegance. Restoring cruft does not help with that. Python 2 idioms that get restored to Python 3 must have real value: unicode literals, wire-protocol interpolations -- I don't feel that this comes any where close to meeting that bar. ~Ethan~ +1 for this summary which echoes my sentiments entirely. Me too. I'm against iteritems and friends coming back. I've been burned in the past with the burden of writing a mapping class with the many methods such a thing must support; both items() and iteritems() and so forth. For the example I have in mind I eventually abandoned the objective of being a full mapping and am going back to just a few methods to support easy element access such as __getitem__ and __contains__. I have a small python module of my own to aid my python 2+3 efforts, and am of the opinion that it is better to add iteritems elper functions to a popular module like six than to left the noise back into the python 3 mapping interface. Cheers, Cameron Simpson c...@zip.com.au ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson c...@zip.com.au wrote: On 20Apr2014 14:32, Mark Lawrence breamore...@yahoo.co.uk wrote: On 20/04/2014 06:31, Ethan Furman wrote: Thank you for taking the time to write this up, Nick. However, I am -1 on it. One of the allures of Python 3 is the increase in simplicity and elegance. Restoring cruft does not help with that. Python 2 idioms that get restored to Python 3 must have real value: unicode literals, wire-protocol interpolations -- I don't feel that this comes any where close to meeting that bar. ~Ethan~ +1 for this summary which echoes my sentiments entirely. Me too. I'm against iteritems and friends coming back. I've been burned in the past with the burden of writing a mapping class with the many methods such a thing must support; both items() and iteritems() and so forth. For the example I have in mind I eventually abandoned the objective of being a full mapping and am going back to just a few methods to support easy element access such as __getitem__ and __contains__. As far as I know, all you have to implement yourself, to support the dict-like interface, are: - __getitem__ - __setitem__ - __delitem__ - __iter__ - __len__ MutableMapping can implement the rest. This wouldn't change with the re-addition of the iter* methods. You really have to use MutableMapping now that keys/items/values are complicated objects: it's much harder to implement dict-like objects from scratch in 3.x than 2.x. -- Devin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 20Apr2014 20:12, Devin Jeanpierre jeanpierr...@gmail.com wrote: On Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson c...@zip.com.au wrote: Me too. I'm against iteritems and friends coming back. I've been burned in the past with the burden of writing a mapping class with the many methods such a thing must support; both items() and iteritems() and so forth. [...] As far as I know, all you have to implement yourself, to support the dict-like interface, are: - __getitem__ - __setitem__ - __delitem__ - __iter__ - __len__ MutableMapping can implement the rest. This wouldn't change with the re-addition of the iter* methods. You really have to use MutableMapping now that keys/items/values are complicated objects: it's much harder to implement dict-like objects from scratch in 3.x than 2.x. Fair point. Thank you, Cameron Simpson c...@zip.com.au Draw little boxes with arrows. It helps. - Michael J. Eager ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Tres Seaver writes: Re-adding features to make the strategy that works less painful is just acknowledging that fact. Whether the strategy that works was anticipated is irrelevant, and the fact that pain *would* be involved was acknowledged all the way back to the days when Python 3000 was still a python-dev in joke rather than something that downstream needed to think about for the future. The question is how much pain, and I'm sorry, but I don't see that the .iterthingee methods involve so much pain. The request for explanation and quantification seems eminently reasonable to me. Mark such features as BBB-only / deprecated-but-never-to-be-removed, and move on: practicality beats purity. Since your statement is a first-order sentence, it's implicitly universally quantified. All is a *lot* of cruft, Tres! Where do *you* propose finally saying the cruft stops here? Also, whatever cruft ends up being included *will* be propagated forward in code that does *not* need it, including new code. Most new code is plagiarized to some degree, and people plagiarize not with a critic's eye, but with an eye to does the API have the semantics I need when it calls that code? Nor do they enable deprecation notices, or read documentation if the reused code Just Works ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 19 April 2014 12:17, Nick Coghlan ncogh...@gmail.com wrote: That may help clarify the tricky warts and edge cases that can arise when moving from the current relatively straightforward and consistent method based approach to a more complicated combination of dedicated syntax and helper functions. OK, I've now updated the PEP to better described the *problem* (rather than skipping ahead to proposing a specific solution - exactly what I was asking people *not* to do at the language summit!), and I now think this is better handled by tweaking the strategies people use when writing or converting to hybrid code, rather than by making any changes to Python 3. The use of more appropriate helper functions should actually make the hybrid code *cleaner* than it would be with any Python 3 API restorations. Accordingly, the PEP itself is now marked as Withdrawn, but it also goes into a lot more detail on the Python 2 mapping iteration APIs, how 2to3 translates them to Python 3, and how I now suggest people translate them to the common subset of Python 2 and 3. Full text of the revised PEP is below, and it has also been updated at http://www.python.org/dev/peps/pep-0469/ Cheers, Nick. = PEP: 469 Title: Migration of dict iteration code to Python 3 Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan ncogh...@gmail.com Status: Withdrawn Type: Standards Track Content-Type: text/x-rst Created: 2014-04-18 Python-Version: 3.5 Post-History: 2014-04-18, 2014-04-21 Abstract For Python 3, PEP 3106 changed the design of the ``dict`` builtin and the mapping API in general to replace the separate list based and iterator based APIs in Python 2 with a merged, memory efficient set and multiset view based API. This new style of dict iteration was also added to the Python 2.7 ``dict`` type as a new set of iteration methods. This means that there are now 3 different kinds of dict iteration that may need to be migrated to Python 3 when an application makes the transition: * Lists as mutable snapshots: ``d.items()`` - ``list(d.items())`` * Iterator objects: ``d.iteritems()`` - ``iter(d.items())`` * Set based dynamic views: ``d.viewitems()`` - ``d.items()`` There is currently no widely agreed best practice on how to reliably convert all Python 2 dict iteration code to the common subset of Python 2 and 3, especially when test coverage of the ported code is limited. This PEP reviews the various ways the Python 2 iteration APIs may be accessed, and looks at the available options for migrating that code to Python 3 by way of the common subset of Python 2.6+ and Python 3.0+. The PEP also considers the question of whether or not there are any additions that may be worth making to Python 3.5 that may ease the transition process for application code that doesn't need to worry about supporting earlier versions when eventually making the leap to Python 3. PEP Withdrawal == In writing the second draft of this PEP, I came to the conclusion that the readability of hybrid Python 2/3 mapping code can actually be best enhanced by better helper functions rather than by making changes to Python 3.5+. The main value I now see in this PEP is as a clear record of the recommended approaches to migrating mapping iteration code from Python 2 to Python 3, as well as suggesting ways to keep things readable and maintainable when writing hybrid code that supports both versions. Notably, I recommend that hybrid code avoid calling mapping iteration methods directly, and instead rely on builtin functions where possible, and some additional helper functions for cases that would be a simple combination of a builtin and a mapping method in pure Python 3 code, but need to be handled slightly differently to get the exact same semantics in Python 2. Static code checkers like pylint could potentially be extended with an optional warning regarding direct use of the mapping iteration methods in a hybrid code base. Mapping iteration models Python 2.7 provides three different sets of methods to extract the keys, values and items from a ``dict`` instance, accounting for 9 out of the 18 public methods of the ``dict`` type. In Python 3, this has been rationalised to just 3 out of 11 public methods (as the ``has_key`` method has also been removed). Lists as mutable snapshots -- This is the oldest of the three styles of dict iteration, and hence the one implemented by the ``d.keys()``, ``d.values()`` and ``d.items()`` methods in Python 2. These methods all return lists that are snapshots of the state of the mapping at the time the method was called. This has a few consequences: * the original object can be mutated freely without affecting iteration over the snapshot * the snapshot can be modified independently of the original object * the snapshot consumes memory proportional to the size of the original mapping The semantic
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Fri, 18 Apr 2014 22:31:29 -0400 Nick Coghlan ncogh...@gmail.com wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. I'm -1 on this. This is destroying the simplification effort of the dict API in Python 3. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, Apr 19, 2014 at 4:31 AM, Nick Coghlan ncogh...@gmail.com wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. I don't see this as a key porting hassle *at all* and I don't understand why they think this would significantly help their porting (it wouldn't). The only real barrier is the str/bytes conversion, really, and this is even more true for projects massively centered around IO, such as Twisted and, I'm sure, the main (only?) reason why Twisted hasn't been ported yet. They will get much more benefit from additions such as PEP-461, which is of great help for verbose protocols such as FTP, not this. -- Giampaolo - http://grodola.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Wouldn't iterkeys simply be an alias for keys and so on? I'm +1 on that. It is a signigificant portion of the incompatibility, and seems like such a minor concession to compatibility to make. K -Original Message- From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Antoine Pitrou Sent: 19. apríl 2014 09:36 To: python-dev@python.org Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods On Fri, 18 Apr 2014 22:31:29 -0400 Nick Coghlan ncogh...@gmail.com wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. I'm -1 on this. This is destroying the simplification effort of the dict API in Python 3. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, 19 Apr 2014 11:41:35 + Kristján Valur Jónsson krist...@ccpgames.com wrote: Wouldn't iterkeys simply be an alias for keys and so on? The PEP shows the following semantics: def iterkeys(self): return iter(self.keys()) def itervalues(self): return iter(self.values()) def iteritems(self): return iter(self.items()) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote:
Wouldn't iterkeys simply be an alias for keys and so on?
I'm +1 on that.
No.
[steve@ando ~]$ python2.7 -c it = {}.iterkeys(); print it is iter(it)
True
[steve@ando ~]$ python3.3 -c it = {}.keys(); print(it is iter(it))
False
It is a signigificant portion of the incompatibility, and seems like
such a minor concession to compatibility to make.
I don't think it is a significant portion of incompatibility. Or at
least, I think that the Twisted folks (or Nick, if he wants to speak for
them) have to justify why it's significant.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 19 Apr 2014 00:27, Steven D'Aprano st...@pearwood.info wrote: On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. It would also considerable add to the cruft of Python 3. One motive for going through the pain of Python 2 to 3 migration was to remove cruft. Adding it back in again is not just an aid to porting but actively making Python 3 a worse (well, less better) experience. The cruft is unavoidable in this case. The decision we face is *where the cruft lives*, and *how much work is involved* in creating that cruft. Status quo: we preserve the purity of the Python 3 mapping API, and require every developer making the transition from Python 2 to Python 3 replace every occurrence of these methods with a helper function that is not idiomatic code in either language. My proposal: we add three trivial helper methods to the Python 3 mapping API. For the cost of 3 additional methods that are easily explained in terms of combining a builtin with other existing methods, a whole pile of work just evaporates for affected segments of the community. So while I'm sympathetic to wanting to ease the 2/3 transition, even at the expense of re-introducing some cruft when unavoidable, I don't think that the difficulty of dealing with dict items|iteritems|viewitems etc. justifies re-adding cruft. The cruft will be there regardless, the only question is whether it exists in the definition of Python 3 or is distributed across all of the single source projects supporting both 2 3. [...] Rationale = Similar in spirit to PEP 414 (which restored explicit Unicode literal support in Python 3.3), this PEP is aimed primarily at helping users that currently feel punished for making use of a feature that needed to be requested explicitly in Python 2, but was effectively made the default behaviour in Python 3. Feel punished? That's awfully strong language. It may even be true, in the sense that some people *feel* that they are being punished, but I think the barrier to doing something about that needs to be a bit higher, namely that they *actually are* being punished. Yes, they are *actually* being punished for using the memory efficient APIs that were being added in Python 2.2. That's why the PEP covers how the transition to Python 3 is harder for them than if they just hadn't cared about memory efficiency in the first place. They're Pythonistas too - they care about readability, and they *don't like* having to add crufty helper functions to all their mapping manipulation code. They also legitimately don't want to put up with all the code churn that results from doing so, requiring additional reviews and retesting of currently working code. I spend a fair bit of time talking to users that have put a lot of work into supporting a language transition that doesn't really help them personally. A non-trivial number of them are deeply, viscerally angry about what they see as pointlessly changing the spelling of a core language feature for no real technical gain. So let me be clear: this is *not* a proposal driven primarily by technical considerations. Rather, it is a social one, where we do something simple and easy and low cost for us to send a clear message to a set of users that feel justifiably angry about the amount of work we imposed on other members of the community by putting Python 2 into maintenance mode that we do value their time and energy, and are willing to show some flexibility in adding not harmful changes to Python 3 that don't significantly increase the complexity of the language, while making it easier to write single source code that looks like idiomatic Python code. I think that if write a helper function is punishment, then nearly every programmer is being punished *all the time*. No, the punishment is replace every usage of the memory efficient iterator based APIs that have existed since Python 2.2 with a helper function because we think that is a reasonable burden to place on you just so we can avoid adding three trivial helper methods in Python 3. Regards, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 18 Apr 2014 23:08, Benjamin Peterson benja...@python.org wrote: On Fri, Apr 18, 2014, at 19:31, Nick Coghlan wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. I personally put this one in the same category as PEP 414 - not particularly useful from a Python 3 perspective, but not really harmful either, and helpful enough from a transition perspective to be worth doing. It doesn't seem to be widely known that Python 2.7's dict has viewkeys()/viewvalues()/viewitems() methods which implement Python 3 dictionary views. Thus, an alternate (or concurrent) proposal could be add these aliases to the Python 3 dictionary type. At any rate, the PEP should mention these methods' existence. It does: = The view based APIs that were added to Python 2.7 don't actually help with the transition process, as they don't exist in Python 3 and hence aren't part of the common subset of Python 2 and Python 3, and also aren't supported by most Python 2 mappings (including the collection ABCs). = I should be more explicit that the other reason they don't really help is because most potential single source code dates back further than 2.7, so it's the iterator based APIs that are needed to avoid code churn when migrating to single source. Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, 19 Apr 2014 10:44:36 -0400 Nick Coghlan ncogh...@gmail.com wrote: I should be more explicit that the other reason they don't really help is because most potential single source code dates back further than 2.7, so it's the iterator based APIs that are needed to avoid code churn when migrating to single source. Why don't you just suggest adding convenience functions to six (or another porting library)? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Does everyone involved know that for x in d.iterkeys() is equivalent to for x in d and works the same in Python 2 and 3? Similarly, list(d) is a simple, fast way to spell the Python 2 semantics of d.keys() that works in both versions (but I doubt it is much needed -- usually the actual code follows up with sorting, so you should use sorted(d)). This doesn't solve itervalues() and iteritems() but I expect those are less common, and for x, y in d.iteritems(): blah is rewritten nicely as for x in d: y = d[x] blah If there is a measurable slowdown in the latter I would be totally okay with some kind of one-element cache for the most recent lookup. I get the social aspect of the PEP, but I think it's too high a price to pay. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 04/19/2014 07:41 AM, Kristján Valur Jónsson wrote: Wouldn't iterkeys simply be an alias for keys and so on? I'm +1 on that. It is a signigificant portion of the incompatibility, and seems like such a minor concession to compatibility to make. K FWIW, I'm +1 on this and other minor changes and concessions to bw compat like this improve the subset language that 2/3 straddling projects need to use. - C ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, Apr 19, 2014 at 3:31 AM, Nick Coghlan ncogh...@gmail.com wrote: Some Python 2 code that uses ``d.keys()`` may be migrated to Python 3 (or the common subset of Python 2 and Python 3) without alteration, but *all* code using the iterator based API requires modification. Code that is migrating to the common subset of Python 2 and 3 and needs to retain the memory efficient implementation that avoids creating an unnecessary list object must switch away from using a method to instead using a helper function (such as those provided by the ``six`` module) I don't know enough about the issues to have an opinion on the proposal as a whole, but the foo.iterkeys() - six.iterkeys(foo) transformation strikes me as exactly the kind of change that can be easily and accurately automated (as in modernize etc.). I assume Glyph et al have considered this option -- do you know why it was rejected? -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 19 Apr 2014 10:53, Guido van Rossum gu...@python.org wrote: Does everyone involved know that for x in d.iterkeys() is equivalent to for x in d and works the same in Python 2 and 3? Similarly, list(d) is a simple, fast way to spell the Python 2 semantics of d.keys() that works in both versions (but I doubt it is much needed -- usually the actual code follows up with sorting, so you should use sorted(d)). This doesn't solve itervalues() and iteritems() but I expect those are less common, and for x, y in d.iteritems(): blah is rewritten nicely as for x in d: y = d[x] blah If there is a measurable slowdown in the latter I would be totally okay with some kind of one-element cache for the most recent lookup. I get the social aspect of the PEP, but I think it's too high a price to pay. OK, I think the main thing I need to add to the PEP next is a clear description of the current state of the art in translating these methods to the common 2/3 subset across the following modes of interaction with the existing Python 2 API: * for loops * comprehensions and generator expressions * iterator object * bound methods * unbound methods That may help clarify the tricky warts and edge cases that can arise when moving from the current relatively straightforward and consistent method based approach to a more complicated combination of dedicated syntax and helper functions. I also asked JP Calderone to trawl the Twisted code base for specific cases where the status quo causes migration problems. Since my main argument is that we should do this to save collective modification and review effort for affected projects (i.e. I think it's a death by 1000 cuts situation rather than a single gaping wound anyone can point to), it would be good if those affected could help with quantifying the scale of the problem so we can make a more informed trade-off between that work and future users of Python 3 needing to learn about the existence of the proposed largely redundant compatibility methods. In several ways, I see my proposal as similar to what we did when PEP 8'ifying the threading.Thread API - the old camel case functions are still there, but clearly marked as only existing for legacy compatibility reasons (they may actually be completely undocumented in Py3 - I don't recall off the top of my head). While I'm personally a big fan of cleaning up APIs and strongly encouraging code modernisation, I've also become convinced that it will be worth our while to start soliciting more quantitative feedback in relation to various decisions to help make sure we're OK with the full consequences of those design decisions. Regards, Nick. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Hi, On Sat, Apr 19, 2014 at 4:14 PM, Steven D'Aprano st...@pearwood.info wrote: On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote: It is a signigificant portion of the incompatibility, and seems like such a minor concession to compatibility to make. I don't think it is a significant portion of incompatibility. Or at least, I think that the Twisted folks (or Nick, if he wants to speak for them) have to justify why it's significant. Assuming this gets included in 3.5 (which will be released around the end of 2015), are they planning to disregard all the previous 3.x releases and then wait a couple more years (so 2018+) for 3.5 to become common? Are they going to support 3.3+ only (with u'...') and have extra cruft for 3.3/3.4 to deal with the missing iter* methods and then remove the cruft once 3.5 is the oldest 3.x release that is supported? What happens if this addition will still not push people to move their code to 3.x and similar requests are made for 3.6+ (and shift what I just said for another 18 months)? Best Regards, Ezio Melotti -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Guido van Rossum writes: Does everyone involved know that for x in d.iterkeys() is equivalent to for x in d and works the same in Python 2 and 3? [...] This doesn't solve itervalues() and iteritems() but I expect those are less common, and for x, y in d.iteritems(): blah is rewritten nicely as for x in d: y = d[x] blah I suppose there's no way to get the compiler to both make for x in d work as above, and make for k, v in d be equivalent to Python 2's for k, v in d.iteritems()? It seems totally analogous to getting both for x in list and for x, y in list_of_couples to DTRT. (To me, anyway.) You'd still be stuck on itervalues(), but at least you'd have the option of for _, v in d (ie, the usual idiom for a value you're going to ignore) without creating a list. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, Apr 19, 2014, at 9:30, Stephen J. Turnbull wrote: Guido van Rossum writes: Does everyone involved know that for x in d.iterkeys() is equivalent to for x in d and works the same in Python 2 and 3? [...] This doesn't solve itervalues() and iteritems() but I expect those are less common, and for x, y in d.iteritems(): blah is rewritten nicely as for x in d: y = d[x] blah I suppose there's no way to get the compiler to both make for x in d work as above, and make for k, v in d be equivalent to Python 2's for k, v in d.iteritems()? It seems totally analogous to getting both for x in list and for x, y in list_of_couples to DTRT. (To me, anyway.) That doesn't make sense. What if your keys are tuples? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Thinking about this more, I expect that an issue might be classes that emulate dicts without being too formal about it (e.g. no ABCs) and then porting code that works for both such class instances and dicts. Many examples of such classes I've seen have a keys() method that returns a list, and for various reasons these classes won't be rewritten to be more like Python 3 as part of the port. And then again, adding iterkeys() back to dict doesn't solve *that* problem, and presumably such a class still has an __iter__() method, and presumably the alternatives I proposed would still work. I am also concerned about the dependency on Python 3.5 that we're building here. I'd much rather be able to use Twisted sooner, with 3.3 or at least 3.4. On Sat, Apr 19, 2014 at 9:17 AM, Nick Coghlan ncogh...@gmail.com wrote: On 19 Apr 2014 10:53, Guido van Rossum gu...@python.org wrote: Does everyone involved know that for x in d.iterkeys() is equivalent to for x in d and works the same in Python 2 and 3? Similarly, list(d) is a simple, fast way to spell the Python 2 semantics of d.keys() that works in both versions (but I doubt it is much needed -- usually the actual code follows up with sorting, so you should use sorted(d)). This doesn't solve itervalues() and iteritems() but I expect those are less common, and for x, y in d.iteritems(): blah is rewritten nicely as for x in d: y = d[x] blah If there is a measurable slowdown in the latter I would be totally okay with some kind of one-element cache for the most recent lookup. I get the social aspect of the PEP, but I think it's too high a price to pay. OK, I think the main thing I need to add to the PEP next is a clear description of the current state of the art in translating these methods to the common 2/3 subset across the following modes of interaction with the existing Python 2 API: * for loops * comprehensions and generator expressions * iterator object * bound methods * unbound methods That may help clarify the tricky warts and edge cases that can arise when moving from the current relatively straightforward and consistent method based approach to a more complicated combination of dedicated syntax and helper functions. I also asked JP Calderone to trawl the Twisted code base for specific cases where the status quo causes migration problems. Since my main argument is that we should do this to save collective modification and review effort for affected projects (i.e. I think it's a death by 1000 cuts situation rather than a single gaping wound anyone can point to), it would be good if those affected could help with quantifying the scale of the problem so we can make a more informed trade-off between that work and future users of Python 3 needing to learn about the existence of the proposed largely redundant compatibility methods. In several ways, I see my proposal as similar to what we did when PEP 8'ifying the threading.Thread API - the old camel case functions are still there, but clearly marked as only existing for legacy compatibility reasons (they may actually be completely undocumented in Py3 - I don't recall off the top of my head). While I'm personally a big fan of cleaning up APIs and strongly encouraging code modernisation, I've also become convinced that it will be worth our while to start soliciting more quantitative feedback in relation to various decisions to help make sure we're OK with the full consequences of those design decisions. Regards, Nick. -- --Guido van Rossum (python.org/~guido) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Apr 19, 2014, at 12:35 PM, Guido van Rossum gu...@python.org wrote: I am also concerned about the dependency on Python 3.5 that we're building here. I'd much rather be able to use Twisted sooner, with 3.3 or at least 3.4. Anyone who is planning on using the bytes modulo formatting is going to be 3.5+ anyways. It seems like trying to fit as many of these compatibility things as Python is willing to do into 3.5 is the best possible solution since it’s likely that for a lot of these hanger-ons 3.5 is likely to be a minimum target anyways. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Benjamin Peterson writes: I suppose there's no way to get the compiler to both make for x in d work as above, and make for k, v in d be equivalent to Python 2's for k, v in d.iteritems()? That doesn't make sense. What if your keys are tuples? Oh, I still think it makes sense. Both x and k would be bound to the key tuples. For example it would work consistently with Common Lisp multiple values. And it's not clear to me that unpacking key tuples would be used anywhere near as often as item unpacking. But Python doesn't have other objects that behave like Common Lisp multiple values, and it would change the meaning of currently correct programs, so it's a non-starter. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 19 Apr 2014 12:29, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, On Sat, Apr 19, 2014 at 4:14 PM, Steven D'Aprano st...@pearwood.info wrote: On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote: It is a signigificant portion of the incompatibility, and seems like such a minor concession to compatibility to make. I don't think it is a significant portion of incompatibility. Or at least, I think that the Twisted folks (or Nick, if he wants to speak for them) have to justify why it's significant. Assuming this gets included in 3.5 (which will be released around the end of 2015), are they planning to disregard all the previous 3.x releases and then wait a couple more years (so 2018+) for 3.5 to become common? Are they going to support 3.3+ only (with u'...') and have extra cruft for 3.3/3.4 to deal with the missing iter* methods and then remove the cruft once 3.5 is the oldest 3.x release that is supported? What happens if this addition will still not push people to move their code to 3.x and similar requests are made for 3.6+ (and shift what I just said for another 18 months)? This isn't really about porting major libraries or frameworks (except perhaps Twisted, which was already blocked by the binary interpolation issue anyway), but about chipping away at the barriers to migration for the large custom in-house code bases, and the wide array of Python *applications* that are part of the reason that people pay companies like Red Hat to provide long term support. Cheers, Nick. Best Regards, Ezio Melotti -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Apr 19, 2014, at 02:12 PM, Giampaolo Rodola' wrote: I don't see this as a key porting hassle *at all* and I don't understand why they think this would significantly help their porting (it wouldn't). The only real barrier is the str/bytes conversion, really, and this is even more true for projects massively centered around IO, such as Twisted and, I'm sure, the main (only?) reason why Twisted hasn't been ported yet. I agree. I've been trying to get rid of iter*() when porting because most of the time, there is no significant memory savings to be achieved anyway. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, Apr 19, 2014 at 4:56 PM, Barry Warsaw ba...@python.org wrote: On Apr 19, 2014, at 02:12 PM, Giampaolo Rodola' wrote: I don't see this as a key porting hassle *at all* and I don't understand why they think this would significantly help their porting (it wouldn't). The only real barrier is the str/bytes conversion, really, and this is even more true for projects massively centered around IO, such as Twisted and, I'm sure, the main (only?) reason why Twisted hasn't been ported yet. I agree. I've been trying to get rid of iter*() when porting because most of the time, there is no significant memory savings to be achieved anyway. +1 -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Apr 18, 2014, at 7:31 PM, Nick Coghlan ncogh...@gmail.com wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. I'm not keen on letting Python 2 leak into Python 3. That defeats one of the goals of Python 3 (simplification and leaving legacy APIs behind a in fresh start). As a Python instructor and coach, I can report that we already have too many methods on dictionaries and that it creates a usability obstacle when deciding which methods to use. In Python 2.7, a dir(dict) or help(dict) presents too many ways to do it. In Python 3.4, we finally have a clean mapping API and it would be a pitty to clutter it up in perpetuity. Raymond ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Stephen J. Turnbull wrote: Benjamin Peterson writes: I suppose there's no way to get the compiler to both make for x in d work as above, and make for k, v in d be equivalent to Python 2's for k, v in d.iteritems()? it would change the meaning of currently correct programs, so it's a non-starter. Maybe what's wanted is a function analogous to enumerate() for mappings instead of sequences. Picking a semi-arbitrary name for now: for k, v in tabulate(d): ... It could be special-cased to recognise dicts and do the appropriate thing for the Python version concerned. If it doesn't recognise the type, it would fall back to a generic implementation like for k in d: v = d[k]: ... -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Greg Ewing writes: Maybe what's wanted is a function analogous to enumerate() for mappings instead of sequences. Picking a semi-arbitrary name for now: for k, v in tabulate(d): I thought this already existed in six, though, with a name that is familiar to Python 2 programmers and not requiring a mental gear change to recall semantics: for k,v in six.iteritems(d): ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, Apr 19, 2014 at 10:38:39AM -0400, Nick Coghlan wrote: On 19 Apr 2014 00:27, Steven D'Aprano st...@pearwood.info wrote: On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. It would also considerable add to the cruft of Python 3. One motive for going through the pain of Python 2 to 3 migration was to remove cruft. Adding it back in again is not just an aid to porting but actively making Python 3 a worse (well, less better) experience. The cruft is unavoidable in this case. The decision we face is *where the cruft lives*, and *how much work is involved* in creating that cruft. How much work is very little. This problem is not of the same magnitude as trying to deal with unicode literals in a polyglot module, or the other string/bytes issues. A lot of the time, we don't even care whether iterating over dict.foo() gives a list, an iterator or a view. For the times we do care, it isn't hard to use a helper. As for where the cruft lives, that's the crux of the matter. In my opinion, the decision hinges on this question: Are iterkeys(), iteritems() and itervalues() the new, preferred APIs for keys(), items() and values(), with the old APIs being kept only for backward compatibility? If so, then adding them to the language is certainly the right place. The old APIs could be deprecated, or even just left with a note in the docs that they aren't yet formerly deprecated but will be some day, in the meantime the new iterator-based APIs are preferred. But if the keys(), items() and values() view-based APIs remain the preferred API, then I don't believe the backwards-compatibility layer belongs in the language. I believe it belongs as an external library, or even just a few helpers on an ad hoc basis. If this is being driven by Twisted, I think that the onus needs to be on them to demonstrate how it will help them. Their official plans are to support Python 3.3, and they seem to have made a lot of progress towards it: http://twistedmatrix.com/trac/wiki/Plan/Python3 so unless they drop 3.3 and 3.4 (do we want to encourage that?) this change won't even help them. Status quo: we preserve the purity of the Python 3 mapping API, and require every developer making the transition from Python 2 to Python 3 replace every occurrence of these methods with a helper function that is not idiomatic code in either language. That is part of the cost of writing polyglot code. It's messy. But that's not new, and it's not unique to 2+3 polyglot code, it happens every time a new feature is added or removed in a point release. My proposal: we add three trivial helper methods to the Python 3 mapping API. For the cost of 3 additional methods that are easily explained in terms of combining a builtin with other existing methods, a whole pile of work just evaporates for affected segments of the community. And a whole lot of additional work suddenly appears for *different* affected segments of the community, e.g. educators, writers. This is where the standard objections to any new language feature come out. Just because this feature is being added for the benefit of transitional 2+3 polyglot code doesn't render these objections irrelevant. I trust I don't need to go through the usual list. By the way, I earlier suggested adding iter* and immediately deprecating them, but I don't believe you commented on that. Even if they are never removed, the deprecation warning would be a very strong signal that they really are only added as an aid to writing 2+3 code, and are not intended as long-term language features. Writers can then ignore the iter* API, or at least relegate it to an appendix, and educators might not be quite able to ignore it but they can at least say don't use them in good conscience. The dict iteration issue for polygot code now becomes easy: just silence the warning, and you're good to go for at least three more years, and likely longer. I think immediate deprecation would be a reasonable compromise position, and would like to hear your thoughts on that. So while I'm sympathetic to wanting to ease the 2/3 transition, even at the expense of re-introducing some cruft when unavoidable, I don't think that the difficulty of dealing with dict items|iteritems|viewitems etc. justifies re-adding cruft. The cruft will be there regardless, the only question is whether it exists in the definition of Python 3 or is distributed across all of the single source projects supporting both 2 3. The same reasoning applies to every change between 2 and 3. If dict.iter* methods get language support, why not all the
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 4/19/2014 10:52 AM, Guido van Rossum wrote: Does everyone involved know that for x in d.iterkeys() is equivalent to for x in d Looking at uses I found by searching code.ohloh.net, the answer is either 'No, people sometimes add a redundant .iterkeys()' or 'people are writing non-dict mapping classes for which it is not redundant (perhaps because their custom class iterates by items rather than keys by default)'. I could not tell from the quoted snippet. and works the same in Python 2 and 3? Similarly, list(d) is a simple, fast way to spell the Python 2 semantics of d.keys() that works in both versions (but I doubt it is much needed -- usually the actual code follows up with sorting, so you should use sorted(d)). This doesn't solve itervalues() and iteritems() but I expect those are less common, ohloh gives about 77,000 python hits for iteritems and 16,000 for itervalues. A large fraction of itervalue hits are definitions rather than uses, often from a compat.py (is this from six?) if sys.version_info[0] = 3: text_type = str string_types = str, iteritems = lambda o: o.items() itervalues = lambda o: o.values() izip = zip else: text_type = unicode string_types = basestring, iteritems = lambda o: o.iteritems() itervalues = lambda o: o.itervalues() from itertools import izip This is three hits for iteritems and three for itervalues and none for the unneeded iterkeys. My guess is that there are 5000 itervalue uses and 7 iteritem uses. There are 1,500,000 python hits for 'for', some unknown fraction of which are 'for key in somedict' or 'for key in somedict.keys()'. There are 13000 for iterkeys. As noted above, this is *not* inflated by 3 hits for each use of compat.py. I think 10% or 15 iterations by key might be a reasonable guess. There are other definition sets that include iterkeys or that define functions that wrap all three bound methods for a particular dict. iterkeys = lambda: d.iterkeys() # py2 iterkeys = lambda: d.keys() # py3 and for x, y in d.iteritems(): blah is rewritten nicely as for x in d: y = d[x] blah If there is a measurable slowdown in the latter I would be totally okay with some kind of one-element cache for the most recent lookup. About three weeks ago, Raymond opened http://bugs.python.org/issue21101 with this claim: It is reasonably common to make two successive dictionary accesses with the same key. I proposed a specialized caching as an alternative to adding new C API functions. Using the iteritems function, there is one simple, extra function call for the entire loop. If the body of the loop takes at lease as long as that one call, the extra time is a non-issue if the dict has more than, say, 20 items. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Thank you for taking the time to write this up, Nick. However, I am -1 on it. One of the allures of Python 3 is the increase in simplicity and elegance. Restoring cruft does not help with that. Python 2 idioms that get restored to Python 3 must have real value: unicode literals, wire-protocol interpolations -- I don't feel that this comes any where close to meeting that bar. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Fri, Apr 18, 2014, at 19:31, Nick Coghlan wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. I personally put this one in the same category as PEP 414 - not particularly useful from a Python 3 perspective, but not really harmful either, and helpful enough from a transition perspective to be worth doing. It doesn't seem to be widely known that Python 2.7's dict has viewkeys()/viewvalues()/viewitems() methods which implement Python 3 dictionary views. Thus, an alternate (or concurrent) proposal could be add these aliases to the Python 3 dictionary type. At any rate, the PEP should mention these methods' existence. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. It would also considerable add to the cruft of Python 3. One motive for going through the pain of Python 2 to 3 migration was to remove cruft. Adding it back in again is not just an aid to porting but actively making Python 3 a worse (well, less better) experience. In the case of u'' syntax for strings, that was (somewhat) unavoidable, as you get a syntax error in Python 3 otherwise. So you cannot write: if sys.version 3: s = uêπд else: s = êπд it simply doesn't work. But you can write: if sys.version 3: items = mydict.iteritems() # or viewitems else: items = mydict.items() Feature discovery is better than explicit version checks: try: items = mydict.iteritems() except AttributeError: items = mydict.items() In my experience, writing polyglot 2+3 code can be easily handled with a few helper functions, which is not the case with unicode string literals. (Non-polygot code of course can just use the methods directly.) I don't see this is a problem to be solved, or even much of a nuisance. Polyglot code is never going to be quite as straightforward or idiomic as non-polyglot code, and that's a good thing, as it reminds the reader that they are dealing with polyglot code. So while I'm sympathetic to wanting to ease the 2/3 transition, even at the expense of re-introducing some cruft when unavoidable, I don't think that the difficulty of dealing with dict items|iteritems|viewitems etc. justifies re-adding cruft. [...] Rationale = Similar in spirit to PEP 414 (which restored explicit Unicode literal support in Python 3.3), this PEP is aimed primarily at helping users that currently feel punished for making use of a feature that needed to be requested explicitly in Python 2, but was effectively made the default behaviour in Python 3. Feel punished? That's awfully strong language. It may even be true, in the sense that some people *feel* that they are being punished, but I think the barrier to doing something about that needs to be a bit higher, namely that they *actually are* being punished. I think that if write a helper function is punishment, then nearly every programmer is being punished *all the time*. That's part of programming. And if every 2+3 helper is seen as punishment that needs to be reversed, then we'll end up with Python 3.5 or 3.6 being virtually the same as Python 2.7 only with a few extra features. Users of list-based iteration in Python 2 that aren't actually relying on those semantics get a free memory efficiency improvement when migrating to Python 3, and face no additional difficulties when migrating via the common subset of Python 2 and 3. By contrast, users that actually want the increased efficiency may have faced a three phase migration process by the time they have fully migrated to Python 3: * original migration to the iterator based APIs after they were added in Python 2.2 That was a long time ago. Surely we're not counting new features introduced a decade ago as part of the cost of migrating to Python 3? * migration to a separate function based API in order to run in the common subset of Python 2 and 3 * eventual migration back to unprefixed method APIs when finally dropping Python 2.7 support at some point in the future I'm not actually seeing the problem here. Forget 2+3, what you've described is surely part of the process of dealing with nearly any multi-version code. Back when I was still writing code to support Python 2.3 through 2.5, I had helper functions like this: def sort(alist, key=None): if key is None: alist.sort() else: try: alist.sort(key=key) except TypeError: # Python too old. Use the DSU idiom. ... When I dropped support for 2.3, I eventually (but not at first) moved back from sort(mylist) to mylist.sort(). I don't see that the situation with iterkeys etc. is terribly different. This PEP proposes to just eliminate all that annoyance by making the iterator based APIs work again in Python 3.5+. As with the restoration of Unicode literals, it does add a bit of additional noise to the definition of Python 3, but it does so while bringing a significant benefit in increasing the size of the common subset of Python 2 and Python 3 and so simplifying the process of migrating to Python 3 for affected Python 2 users. To me, this feels more like re-adding cruft for trivial benefit. I would want to see justification for why this gives *significant* benefit before I could
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 4/18/2014 10:31 PM, Nick Coghlan wrote: After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. I hate this idea. It strikes me as junking up Python3 with stuff it is well rid of. I think anything that can be left to the transition modules should be. The u'' syntax had to be in the language itself. This does not have to be. I personally put this one in the same category as PEP 414 - When I suggested that PEP 414 might be seen as a precedent for restoring more of Py2, I was trashed for saying so. No, no, u'' is a unique case. [it is] This will be the last proposal like this. What will come next? not particularly useful from a Python 3 perspective, but not really harmful either, It makes the language a bit harder to learn and remember and slightly more confusing. It will not help inter-operating with Python before 3.5, at the earliest and cannot be backported. Most things in an independent module can be used with any 3.x. I would have preferred that you started by presenting the problem on python-ideas with possible solutions, rather than as a finished PEP pushing my least favorite solution. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
