A couple of people have said that 'native string' is spelt 'str', but I'm not
sure that's the right answer. For example, 2.x's cString.StringIO
expects native strings, not Unicode:
Your counter-example is non-ASCII characters/bytes. I doubt that this
is a valid
use case; in a "native" string
Hi,
On 2/28/12 12:16 AM, mar...@v.loewis.de wrote:
> Armin, I propose that you correct the *factual* deficits of the PEP
> (i.e. remove all claims that cannot be supported by facts, or are otherwise
> incorrect or misleading). Many readers here would be more open to accepting
> the PEP if it was f
Hi,
On 2/27/12 11:54 PM, Steven D'Aprano wrote:
> That would be one order of magnitude.
I am aware of that :-)
Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
On Mon, Feb 27, 2012 at 19:53, Victor Stinner
wrote:
> A frozendict type is a common request from users and there are various
> implementations. There are two main Python implementations:
Perhaps this should also detail why namedtuple is not a viable alternative.
Cheers,
Dirkjan
___
>> The PEP author is supposed to collect all arguments, even the ones he
>> doesn't agree with, and refute them.
> I brought up all the arguments that were I knew about before I submitted
> this mailinglist thread and I had since not updated it.
This is fine, of course. I still hope you will updat
Am 27.02.2012 22:35, schrieb Armin Ronacher:
> Hi,
>
> On 2/27/12 4:44 PM, mar...@v.loewis.de wrote:
>> Maybe I'm missing something, but there doesn't seem to be a benchmark
>> that measures the 2to3 performance, supporting the claim that it
>> runs "two orders of magnitude" slower (which I'd inte
On Tue, Feb 28, 2012 at 08:51, Vinay Sajip wrote:
> Lennart Regebro gmail.com> writes:
>
>> I'm +1 on the PEP, for reasons already repeated here.
>> We need three types of strings when supporting both Python 2 and
>> Python 3. A binary string, a unicode string and a "native" string, ie
>> one tha
Victor Stinner wrote:
The blacklist implementation has a major issue: it is still possible
to call write methods of the dict class (e.g. dict.set(my_frozendict,
key, value)).
It is also possible to use ctypes and violate even more invariants.
For most purposes, this falls under "consenting adult
> A frozendict type is a common request from users and there are various
>> implementations. There are two main Python implementations:
>
> Perhaps this should also detail why namedtuple is not a viable alternative.
It doesn't have the same API. Example: frozendict[key] vs
namedtuple.attr (namedtu
On 28.2.2012 01:16, mar...@v.loewis.de wrote:
Armin, I propose that you correct the *factual* deficits of the PEP
He cannot, because he would have to throw away whole PEP ... it is all
based on non-sensical concept of "native string". There is no such
animal (there are only strings and bytes,
On Tue, 28 Feb 2012 10:02:46 +0100
"Martin v. Löwis" wrote:
>
> On the contrary, I'd expect that the build time using 2to3 is
> significantly shorter than the test suite run times, *in particular*
> for large projects. For example, for Django, 2to3 takes less than
> 3 minutes (IIRC), and the test
On Tue, Feb 28, 2012 at 5:56 PM, Matej Cepl wrote:
> He cannot, because he would have to throw away whole PEP ... it is all based
> on non-sensical concept of "native string". There is no such animal (there
> are only strings and bytes, although they are incorrectly named Unicode
> strings and str
> I think you need to elaborate on your use cases further, ...
A frozendict can be used as a member of a set or as a key in a dictionary.
For example, frozendict is indirectly needed when you want to use an
object as a key of a dict, whereas one attribute of this object is a
dict. Use a frozendic
On Tue, 28 Feb 2012 21:42:54 +1000
Nick Coghlan wrote:
> But the existing approaches require that, in order to be
> forward compatible with Python 3, a program must be made *worse* in
> Python 2 (i.e. harder to read and harder to write correctly for
> someone that hasn't learned Python 3 yet).
Wr
On Tue, 28 Feb 2012 12:45:54 +0100
Victor Stinner wrote:
> > I think you need to elaborate on your use cases further, ...
>
> A frozendict can be used as a member of a set or as a key in a dictionary.
>
> For example, frozendict is indirectly needed when you want to use an
> object as a key of a
Antoine Pitrou wrote:
On Tue, 28 Feb 2012 12:45:54 +0100
Victor Stinner wrote:
I think you need to elaborate on your use cases further, ...
A frozendict can be used as a member of a set or as a key in a dictionary.
For example, frozendict is indirectly needed when you want to use an
object as
Lennart Regebro gmail.com> writes:
> Distribute helps with this. I think we might have to add a support in
> distribute to easily exclude the fixer that removes u''-prefixes, I
> don't remember if there is an "exclude" feature.
We might be at cross purposes here. I don't see how Distribute hel
On 28 February 2012 12:07, Mark Shannon wrote:
>>> frozendict helps also in threading and multiprocessing.
>>
>> How so?
>
> Inter process/task communication requires copying. Inter/intra thread
> communication uses reference semantics. To ensure these are the same,
> the objects used in communica
>> A frozendict can be used as a member of a set or as a key in a dictionary.
>>
>> For example, frozendict is indirectly needed when you want to use an
>> object as a key of a dict, whereas one attribute of this object is a
>> dict.
>
> It isn't. You just have to define __hash__ correctly.
Define
Updated patch and more justifications.
New patch:
- dict doesn't inherit from frozendict anymore
- frozendict is a subclass of collections.abc.Mutable
- more tests
> * frozendict.__hash__ computes hash(frozenset(self.items())) and
> caches the result is its private hash attribute
hash(frozen
On Tue, Feb 28, 2012 at 9:52 PM, Antoine Pitrou wrote:
> On Tue, 28 Feb 2012 21:42:54 +1000
> Nick Coghlan wrote:
>> But the existing approaches require that, in order to be
>> forward compatible with Python 3, a program must be made *worse* in
>> Python 2 (i.e. harder to read and harder to write
On Tue, 28 Feb 2012 12:07:32 +
Mark Shannon wrote:
> Antoine Pitrou wrote:
> > On Tue, 28 Feb 2012 12:45:54 +0100
> > Victor Stinner wrote:
> >>> I think you need to elaborate on your use cases further, ...
> >> A frozendict can be used as a member of a set or as a key in a dictionary.
> >>
>
On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip wrote:
> If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
> potentially involve running a fixer on all files in the project every time a
> change is made, writing to a separate directory, or else a fixer which is
> integrated in
Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
> If you're using separate branches, then your Python 2 code isn't being
> made forward compatible with Python 3. Yes, it avoids making your
> Python 2 code uglier, but it means maintaining two branches in
> parallel until you drop Pyt
Hi,
I don't know if an implementation of the frozendict actually exists,
but if anyone is planning on writing one then can I suggest that they
take a look at my new dict implementation:
http://bugs.python.org/issue13903
https://bitbucket.org/markshannon/cpython_new_dict/
Making dicts immutable (
On Tue, 28 Feb 2012 13:14:15 +0100
Victor Stinner wrote:
>
> > See also the PEP 351.
>
> I read the PEP and the email explaining why it was rejected.
I think you should write a separate PEP and explain the use cases
clearly.
cheers
Antoine.
___
Py
Victor Stinner wrote:
>> See also the PEP 351.
>
> I read the PEP and the email explaining why it was rejected.
>
> Just to be clear: the PEP 351 tries to freeze an object, try to
> convert a mutable or immutable object to an immutable object. Whereas
> my frozendict proposition doesn't convert a
Il 28 febbraio 2012 13:19, Antoine Pitrou ha scritto:
>
> Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
>> If you're using separate branches, then your Python 2 code isn't being
>> made forward compatible with Python 3. Yes, it avoids making your
>> Python 2 code uglier, but it me
On Tue, Feb 28, 2012 at 10:19 PM, Antoine Pitrou wrote:
>
> Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
>> If you're using separate branches, then your Python 2 code isn't being
>> made forward compatible with Python 3. Yes, it avoids making your
>> Python 2 code uglier, but it
Nick Coghlan gmail.com> writes:
>
> On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip yahoo.co.uk>
wrote:
> > If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
> > potentially involve running a fixer on all files in the project every time a
> > change is made, writing to a se
v.loewis.de> writes:
>
> > A couple of people have said that 'native string' is spelt 'str', but I'm
> > not
> > sure that's the right answer. For example, 2.x's cString.StringIO
> > expects native strings, not Unicode:
>
> Your counter-example is non-ASCII characters/bytes. I doubt that th
28.02.12 14:14, Nick Coghlan написав(ла):
> However, that's the wrong question.
> The right question is "Does PEP 414 make porting substantially
> *easier*, by significantly reducing the volume of code that needs to
> change in order to attain Python 3 compatibility?".
Another pertinent question:
On Tue, 28 Feb 2012 22:21:11 +1000, Nick Coghlan wrote:
> On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip wrote:
> > If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
> > potentially involve running a fixer on all files in the project every time a
> > change is made, writing
On 28/02/2012 14.19, Antoine Pitrou wrote:
Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
If you're using separate branches, then your Python 2 code isn't being
made forward compatible with Python 3. Yes, it avoids making your
Python 2 code uglier, but it means maintaining two br
On Feb 28, 2012, at 08:41 AM, R. David Murray wrote:
>Hmm. It seems to me that this argument implies that PEP 414 is just
>as likely to *slow down* adoption of Python3 as it is to speed it up,
>since if this issue is as big a barrier as indicated, many potential
>porters may choose to wait until
M.-A. Lemburg wrote:
Victor Stinner wrote:
See also the PEP 351.
I read the PEP and the email explaining why it was rejected.
Just to be clear: the PEP 351 tries to freeze an object, try to
convert a mutable or immutable object to an immutable object. Whereas
my frozendict proposition doesn't
Armin Ronacher active-4.com> writes:
> If by str() you mean using "str('x')" as replacement for 'x' in both 2.x
> and 3.x with __future__ imports as a replacement for native string
> literals, please mention why this is better than u(), s(), n() etc. It
> would be equally slow than a custom wra
On Feb 28, 2012, at 10:49 PM, Nick Coghlan wrote:
>On Tue, Feb 28, 2012 at 10:19 PM, Antoine Pitrou wrote:
>> Again that's wrong. If you cleverly use 2to3 to port between branches,
>> patches only have to be written against the 2.x version.
>
>Apparently *you* know how to do that, but I don't. If
Nick Coghlan gmail.com> writes:
> tools. But the existing approaches require that, in order to be
> forward compatible with Python 3, a program must be made *worse* in
> Python 2 (i.e. harder to read and harder to write correctly for
> someone that hasn't learned Python 3 yet). Restoring unicode
On Tue, Feb 28, 2012 at 09:53, Barry Warsaw wrote:
> On Feb 28, 2012, at 08:41 AM, R. David Murray wrote:
>
> >Hmm. It seems to me that this argument implies that PEP 414 is just
> >as likely to *slow down* adoption of Python3 as it is to speed it up,
> >since if this issue is as big a barrier a
Antoine Pitrou pitrou.net> writes:
> Wrong. The separate branches approach allows you to have a clean
> Python 3 codebase without crippling the Python 2 codebase.
There may be warts in a single codebase (you usually can't have something for
nothing), but it's not necessarily *crippled* when runn
Il 28 febbraio 2012 15:20, Ezio Melotti ha scritto:
> On 28/02/2012 14.19, Antoine Pitrou wrote:
>>
>> Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit :
>>>
>>> If you're using separate branches, then your Python 2 code isn't being
>>> made forward compatible with Python 3. Yes, it av
On Tue, Feb 28, 2012 at 09:04, Barry Warsaw wrote:
> We really need to stop saying that porting to Python 3 is hard, or should be
> delayed. It's not in the vast majority of cases. Yes, there are warts, and
> we should continue to improve Python 3 so it gets easier, but by no means is
> it impos
On Feb 28, 2012, at 10:23 AM, Brett Cannon wrote:
>Well, when the code is committed I will update the porting HOWTO and push
>the __future__ imports first since they cover more versions of Python (i.e.
>Python 3.2). But I will mention the options that skip the __future__
>imports for those that ch
Serhiy Storchaka gmail.com> writes:
> Another pertinent question: "What are disadvantages of PEP 414 is adopted?"
It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single
codebase across 2.x and 3.x. However, it only does this if your 3.x interest is
3.3+. If you also want to
Vinay Sajip wrote:
Serhiy Storchaka gmail.com> writes:
Another pertinent question: "What are disadvantages of PEP 414 is adopted?"
It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single
codebase across 2.x and 3.x. However, it only does this if your 3.x interest is
3.3+
Ezio Melotti gmail.com> writes:
> For every CPython bug that I fix I first apply the patch on 2.7, then on
> 3.2 and then on 3.3.
> Most of the time I don't even need to change anything while applying the
> patch to 3.2, sometimes I have to do some trivial fixes. This is also
> true for ano
Hi Armin,
Could you please remove from the PEP the following statement:
"""As it stands, Python 3 is currently a bad choice for long-term
investments, since the ecosystem is not yet properly developed, and
libraries are still fighting with their API decisions for Python 3."""
While it may be a
Steven D'Aprano pearwood.info> writes:
> I don't think it's fair to say it makes it *more* painful. Fair to say it
> doesn't make it less painful, but adding u'' to 3.3+ doesn't make it harder
> to
> port from 2.x to 3.1+. You're merely no better off with it than without it.
No, it actually d
Big +1.
Indeed, this whole Ellipsis approach is just an awful hack.
-
Yury
On 2012-02-26, at 8:30 PM, Benjamin Peterson wrote:
> PEP: 415
> Title: Implementing PEP 409 differently
> Version: $Revision$
> Last-Modified: $Date$
> Author: Benjamin Peterson
> Status: Draft
> Type: Standards Track
On Feb 28, 2012, at 11:29 AM, Yury Selivanov wrote:
>Could you please remove from the PEP the following statement:
>
>"""As it stands, Python 3 is currently a bad choice for long-term
>investments, since the ecosystem is not yet properly developed, and
>libraries are still fighting with their AP
In the end, that's not particularly relevant, because you don't have to
run the test suite entirely; when working on small changes, you usually
re-run the impacted parts of the test suite until everything goes fine;
on the other hand, 2to3 *has* to run on the entire code base.
Not at all. If you
If PEP 414 helps some projects migrate to Python 3, great.
But I really hope we as a community don't perpetuate the myth that you cannot
port to Python 3 without this, and I hope that we spend as much effort on
educating other Python developers on how to port to Python 3 *right now*
supporting Py
v.loewis.de> writes:
> One thing that the PEP will certainly achieve is to spread the myth that
> you cannot port to Python 3 if you also want to support Python 2.5. That's
> because people will accept the "single source" approach as the one right
> way, and will accept that this only works well
On Tue, Feb 28, 2012 at 12:07, Vinay Sajip wrote:
> v.loewis.de> writes:
>
> > One thing that the PEP will certainly achieve is to spread the myth that
> > you cannot port to Python 3 if you also want to support Python 2.5.
> That's
> > because people will accept the "single source" approach as
>> * frozendict values must be immutable, as dict keys
>
> Why? That may be useful, but an immutable dict whose values
> might mutate is also useful; by forcing that choice, it starts
> to feel too specialized for a builtin.
Hum, I realized that calling hash(my_frozendict) on a frozendict
instan
On 28/02/2012 18.08, Vinay Sajip wrote:
Ezio Melotti gmail.com> writes:
For every CPython bug that I fix I first apply the patch on 2.7, then on
3.2 and then on 3.3.
Most of the time I don't even need to change anything while applying the
patch to 3.2, sometimes I have to do some trivial fixes
Brett Cannon python.org> writes:
> Changes to http://docs.python.org/howto/pyporting.html are welcome. I tried to
> make sure it exposed all possibilities with tips on how to support as far back
> as Python 2.5.
Right, will take a look. FYI a Google search for "python 3 porting guide" shows
the
On Tue, Feb 28, 2012 at 11:51, Vinay Sajip wrote:
> Brett Cannon python.org> writes:
>
>> Changes to http://docs.python.org/howto/pyporting.html are welcome. I tried
>> to
>> make sure it exposed all possibilities with tips on how to support as far
>> back
>> as Python 2.5.
>
> Right, will take
Victor Stinner wrote:
* frozendict values must be immutable, as dict keys
Why? That may be useful, but an immutable dict whose values
might mutate is also useful; by forcing that choice, it starts
to feel too specialized for a builtin.
Hum, I realized that calling hash(my_frozendict) on a fr
On 2/28/2012 7:10 AM, Vinay Sajip wrote:
The PEP 314 approach seems to assume that that if things work on 3.3,
they will work on 3.2/3.1/3.0 without any changes other than
replacing u'xxx' with 'xxx'.
(Delete 3.0. 3.1 is also less of a concern.) It actually assumes that if
things work on 3.3
In http://mail.python.org/pipermail/python-dev/2012-February/117070.html
Vinay Sajip wrote:
> It's moot, but as I see it: the purpose of PEP 414 is to facilitate a
> single codebase across 2.x and 3.x. However, it only does this if your
> 3.x interest is 3.3+
For many people -- particularly tho
On Feb 28, 2012, at 10:59 AM, Jim J. Jewett wrote:
>For many people -- particularly those who haven't ported yet -- 3.x
>will mean 3.3+. There are some who will support 3.2 because it is a
>LTS release on some distribution, just as there were some who supported
>Python 1.5 (but not 1.6) long into
Steven D'Aprano wrote:
> M.-A. Lemburg wrote:
>> Victor Stinner wrote:
See also the PEP 351.
>>> I read the PEP and the email explaining why it was rejected.
>>>
>>> Just to be clear: the PEP 351 tries to freeze an object, try to
>>> convert a mutable or immutable object to an immutable object
Here's what I know:
We don't add features to bug-fix releases.
u'' is considered a feature.
By not backporting to 3.1 and 3.2 we are not easing the migration pains
from 2.x.
Here's what I don't know:
Why is readding u'' a feature and not a bug? (Just had a thought about
this -- because the
2012/2/28 Ethan Furman :
> Here's what I know:
>
> We don't add features to bug-fix releases.
> u'' is considered a feature.
> By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> 2.x.
>
>
> Here's what I don't know:
>
> Why is readding u'' a feature and not a bug? (Just
On Tue, Feb 28, 2012 at 14:27, Ethan Furman wrote:
> Here's what I know:
>
> We don't add features to bug-fix releases.
> u'' is considered a feature.
> By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> 2.x.
Let's say it's 2013 and 3.3 has been out for a few months an
On Tue, 2012-02-28 at 15:54 -0500, Benjamin Peterson wrote:
> 2012/2/28 Ethan Furman :
> > Here's what I know:
> >
> > We don't add features to bug-fix releases.
> > u'' is considered a feature.
> > By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> > 2.x.
> >
> >
> > He
On Tue, 28 Feb 2012 16:23:40 -0500
Chris McDonough wrote:
> On Tue, 2012-02-28 at 15:54 -0500, Benjamin Peterson wrote:
> > 2012/2/28 Ethan Furman :
> > > Here's what I know:
> > >
> > > We don't add features to bug-fix releases.
> > > u'' is considered a feature.
> > > By not backporting to 3.1 a
On Feb 28, 2012, at 03:54 PM, Benjamin Peterson wrote:
>> If there is already a FAQ entry feel free to point me to it, but I would
>> still be curious why, in this instance, practicality does not beat purity?
>
>Because it's practical not to break bugfix releases with new features.
And because no
On Tue, 2012-02-28 at 16:48 -0500, Barry Warsaw wrote:
> On Feb 28, 2012, at 03:54 PM, Benjamin Peterson wrote:
>
> >> If there is already a FAQ entry feel free to point me to it, but I would
> >> still be curious why, in this instance, practicality does not beat purity?
> >
> >Because it's practi
On Wed, Feb 29, 2012 at 8:17 AM, Chris McDonough wrote:
> But yeah. A year from now I wouldn't remember which version of 3.2 got
> a new feature, and neither would anybody else. The no-new-features
> guidelines are useful in the real world this way, because they represent
> a coherent policy, as
Why is readding u'' a feature and not a bug?
There is a really simple litmus test for whether something is a bug:
does it deviate from the specification?
In this case, the specification is the grammar, and the implementation
certainly doesn't deviate from it. So it can't be a bug.
Regards,
Mar
Nick Coghlan gmail.com> writes:
> Also, I think there may be some confusion about Armin's plan to handle
> 3.2 - he aims to write an *import hook* that accepts the u/U prefixes
> during tokenisation, not a source-to-source transform like 2to3. It's
I must confess, I thought it was a source-to-so
Le 28/02/2012 13:48, Giampaolo Rodolà a écrit :
> Il 28 febbraio 2012 13:19, Antoine Pitrou ha scritto:
>> IMO, maintaining two branches shouldn't be much more work than
>> maintaining hacks so that a single codebase works with two different
>> programming languages.
>
> Would that mean distribut
On Tue, Feb 28, 2012 at 13:10, Vinay Sajip wrote:
> We might be at cross purposes here. I don't see how Distribute helps, because
> the use case I'm talking about is not about distributing or installing stuff,
> but iteratively changing and testing code which needs to work on 2.6+, 3.2 and
> 3.3+.
All the various strategies for supporting Python 2 and Python 3 as
well as their various drawbacks and ways around this is covered in my
book, chapter 2. :-)
http://python3porting.com/strategies.html
I may be too late to point this out, but it feels like this discussion
could have been shorter if
On Tue, Feb 28, 2012 at 16:30, Giampaolo Rodolà wrote:
> Il 28 febbraio 2012 15:20, Ezio Melotti ha scritto:
>> (Note: there are also other costs -- e.g. releasing -- that I haven't
>> considered because they don't affect me personally, but I'm not sure they
>> are big enough to make the two-bran
On Tue, Feb 28, 2012 at 16:39, Vinay Sajip wrote:
> Serhiy Storchaka gmail.com> writes:
>
>> Another pertinent question: "What are disadvantages of PEP 414 is adopted?"
>
> It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single
> codebase across 2.x and 3.x.
The bytes/nativ
On Tue, Feb 28, 2012 at 21:27, Ethan Furman wrote:
> Here's what I know:
>
> We don't add features to bug-fix releases.
> u'' is considered a feature.
> By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> 2.x.
If this is added to 3.2.3, then some programs will work with
mar...@v.loewis.de writes:
> One thing that the PEP will certainly achieve is to spread the myth that
> you cannot port to Python 3 if you also want to support Python 2.5. That's
> because people will accept the "single source" approach as the one right way,
> and will accept that this only wo
On Wed, Feb 29, 2012 at 5:23 PM, Stephen J. Turnbull wrote:
> mar...@v.loewis.de writes:
>
> > One thing that the PEP will certainly achieve is to spread the myth that
> > you cannot port to Python 3 if you also want to support Python 2.5. That's
> > because people will accept the "single sourc
82 matches
Mail list logo
