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
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
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
-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
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
-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
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
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
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
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
-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.
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
-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
: 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
-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.
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 +
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
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
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
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
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
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
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
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
@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
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
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))
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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),
53 matches
Mail list logo
