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
Hi,
I just joined python-dev because I found the need to add some code to
paper over python3's subprocess API, and I'm wondering whether I'm
missing something.
On python2 and python3, the (only?) way to get utf-8 arguments to
subprocess was to ensure that all unicode strings are encoded into
byte
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
On 04/13/2014 04:58 PM, R. David Murray wrote:
On Sun, 13 Apr 2014 15:59:36 -0400, Terry Reedy wrote:
On 4/13/2014 4:11 AM, �ukasz Langa wrote:
On Apr 13, 2014, at 12:48 AM, Stefan Behnel wrote:
So, what I've learned from seven years of Cython is that static typing in
signatures is actually
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 Mon, 24 Mar 2014 10:10:18 +0100
"M.-A. Lemburg" wrote:
>
> The OpenSSL version used for 2.7.6 is 0.9.8y.
>
> Upgrading to 1.0.0 or 1.0.1 will likely need a few minor tweaks, but
> not cause general breakage - at least that's my experience with
> the egenix-pyopenssl distribution.
For the rec
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(
> -Original Message-
> From: Nick Coghlan [mailto:ncogh...@gmail.com]
>
> > 2. Feature enhancement to 2.8. Take a robust and popular version of
> > python and add some of the language goodies that have been added to
> > 3.x and that don’t have an inherent 3.x aspect. Yield from.
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
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
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 Fri, 18 Apr 2014 11:58:59 -0400
Nick Coghlan wrote:
>
> Software integrators:
>
> * Linux distributions and other operating system vendors
> * Sumo redistributions (commercial or otherwise)
> * "Python based environments" (PTVS, Enthought Canopy, wakari.io,
> Python Anywhere, etc)
> * Softwar
Hi Jim,
On 18 April 2014 23:46, Jim J. Jewett wrote:
> (2) Is "the item will be hashed at least once" a language guarantee?
I think that a reasonable implementation needs to hash at least once
all keys that are added to the dictionary. Otherwise we end up, as
you said, with a dictionary that c
On Fri, Apr 18, 2014 at 11:28 PM, Donald Stufft wrote:
>
> On Apr 18, 2014, at 6:24 PM, Nick Coghlan wrote:
>
> > On 18 April 2014 18:17, Paul Moore wrote:
> >> On 18 April 2014 22:57, Donald Stufft wrote:
> >>> Maybe Nick meant ``pip install ipython[all]`` but I don’t actually
> know what tha
34 matches
Mail list logo
