Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-21 Thread Kristján Valur Jónsson
> -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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-21 Thread Luca Sbardella
Hi Guys, please don't do it! We don't need this legacy really. On 21 April 2014 08:41, Armin Rigo wrote: > Hi Nick, > > On 21 April 2014 07:39, Nick Coghlan wrote: > > Notably, I recommend that hybrid code avoid calling mapping iteration > > methods directly, and instead rely on builtin functi

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-21 Thread Kristján Valur Jónsson
> -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 als

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-21 Thread Ethan Furman
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 obje

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-21 Thread Armin Rigo
Hi Nick, On 21 April 2014 07:39, Nick Coghlan 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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-21 Thread Terry Reedy
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 d

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Nick Coghlan
On 19 April 2014 12:17, Nick Coghlan 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'v

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Stephen J. Turnbull
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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Cameron Simpson
On 20Apr2014 20:12, Devin Jeanpierre wrote: On Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson 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 i

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Devin Jeanpierre
On Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson wrote: > On 20Apr2014 14:32, Mark Lawrence 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 si

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Cameron Simpson
On 20Apr2014 14:32, Mark Lawrence 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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Steven D'Aprano
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 itera

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Devin Jeanpierre
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 i

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Kristján Valur Jónsson
> -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. > > N

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Kristján Valur Jónsson
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 it

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Kristján Valur Jónsson
> -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()

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Steven D'Aprano
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 interato

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Tres Seaver
-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.

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Nick Coghlan
On 20 Apr 2014 08:14, "Markus Unterwaditzer" 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 compatib

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Mark Lawrence
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 rea

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Markus Unterwaditzer
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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-20 Thread Paul Moore
On 20 April 2014 03:49, Steven D'Aprano 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 decisio

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Ethan Furman
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-protoco

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Terry Reedy
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 ma

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Steven D'Aprano
On Sat, Apr 19, 2014 at 10:38:39AM -0400, Nick Coghlan wrote: > On 19 Apr 2014 00:27, "Steven D'Aprano" 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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Stephen J. Turnbull
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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Greg Ewing
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,

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Raymond Hettinger
On Apr 18, 2014, at 7: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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Eric Snow
On Sat, Apr 19, 2014 at 4:56 PM, Barry Warsaw 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/

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Barry Warsaw
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 pr

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Nick Coghlan
On 19 Apr 2014 12:29, "Ezio Melotti" wrote: > > Hi, > > On Sat, Apr 19, 2014 at 4:14 PM, Steven D'Aprano 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 com

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Stephen J. Turnbull
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 se

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Donald Stufft
On Apr 19, 2014, at 12:35 PM, Guido van Rossum 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+ a

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Guido van Rossum
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 v

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Benjamin Peterson
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 exp

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Stephen J. Turnbull
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(): " is > rewr

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Ezio Melotti
Hi, On Sat, Apr 19, 2014 at 4:14 PM, Steven D'Aprano 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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Nick Coghlan
On 19 Apr 2014 10:53, "Guido van Rossum" 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 (bu

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Nathaniel Smith
On Sat, Apr 19, 2014 at 3:31 AM, Nick Coghlan 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 co

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Chris McDonough
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 chang

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Guido van Rossum
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 cod

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Antoine Pitrou
On Sat, 19 Apr 2014 10:44:36 -0400 Nick Coghlan 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 s

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Nick Coghlan
On 18 Apr 2014 23:08, "Benjamin Peterson" 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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Nick Coghlan
On 19 Apr 2014 00:27, "Steven D'Aprano" 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

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Steven D'Aprano
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(

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Antoine Pitrou
On Sat, 19 Apr 2014 11:41:35 + Kristján Valur Jónsson 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 i

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Kristján Valur Jónsson
-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 wrote: > After spending some time talking

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Giampaolo Rodola'
On Sat, Apr 19, 2014 at 4:31 AM, 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 lik

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-19 Thread Antoine Pitrou
On Fri, 18 Apr 2014 22:31:29 -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 li

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-18 Thread Terry Reedy
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), witho

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-18 Thread Steven D'Aprano
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 (

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-18 Thread Benjamin Peterson
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

[Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

2014-04-18 Thread Nick Coghlan
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