> -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
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
> -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
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
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
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
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
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 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
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
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
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
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
> -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
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
> -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()
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
-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 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
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
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 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
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
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
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
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
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,
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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(
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
-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
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
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
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
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 (
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
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
53 matches
Mail list logo