Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-25 Thread Tshepang Lekhonkhobe 
On Sat, Feb 25, 2012 at 05:10, Ned Batchelder  wrote:
>  Has Python *ever* removed a feature except in X.0 releases?

I thought this happens all the time, but with deprecations first. Is
that not the case?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-25 Thread Tshepang Lekhonkhobe 
On Sat, Feb 25, 2012 at 02:20,   wrote:
> Zitat von Tshepang Lekhonkhobe :
>> On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" 
>>> If that issue was getting serious, I would prefer if the .format method
>>> was deprecated, and only % formatting was kept.
>>
>> Why is that? Isn't .format regarded superior?
>
> I find the .format syntax too complicated and difficult to learn. It has
> so many bells and whistles, making it more than just a *mini* language.
> So for my own code, I always prefer % formatting for simplicity.

I find that strange, especially for an expert Python dev. I, a newbie,
find it far friendlier (and easier for a new programmer to grasp).
Maybe it's because I use it all the time, and you don't?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

2012-02-25 Thread Tshepang Lekhonkhobe 
On Sat, Feb 25, 2012 at 05:32, Matt Joiner  wrote:
> There are so many third party modules languishing because inferior forms
> exist in the stdlib, and no centralized method for their recommendation and
> discovery.

That's interesting. Do you have a list of these? Maybe a blog post somewhere?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

2012-02-25 Thread Nick Coghlan 
On Sat, Feb 25, 2012 at 4:59 AM, Brett Cannon  wrote:
> On Fri, Feb 24, 2012 at 13:23, Georg Brandl  wrote:
>> Am 24.02.2012 18:46, schrieb Antoine Pitrou:
>> > Overall, I like the principle of this PEP, but I really dislike the
>> > dual version numbering it introduces. Such a numbering scheme will be
>> > cryptic and awkward for anyone but Python specialists.
>>
>> I agree.
>
> Ditto.

And, in contrast, I believe that the free-wheeling minor version
number proposed in PEP 407 is a train wreck and PR disaster waiting to
happen. I find it interesting that we can so readily agree that using
the major version number in any way is impossible due to the ongoing
Python 2 -> 3 transition, yet I get so much pushback on the idea that
messing with the implications of changing the *minor* version number
will unnecessarily confuse or upset users.

I spent quite a bit of time thinking about the ways people *use* the
CPython version number, and it switched me from mildly preferring a
separate version number for the standard library to being a strong
*opponent* of increasing the rate of change for the minor version
number. Anyway, the PEP now describes the user scenarios that
convinced me that a separate version number for the standard library
was the right way to go:
http://www.python.org/dev/peps/pep-0413/#user-scenarios

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-25 Thread Steven D'Aprano 

Tshepang Lekhonkhobe wrote:

On Sat, Feb 25, 2012 at 05:10, Ned Batchelder  wrote:

 Has Python *ever* removed a feature except in X.0 releases?


I thought this happens all the time, but with deprecations first. Is
that not the case?


Hardly "all the time". Only when absolutely necessary, the exception being the 
2.x -> 3.x transition which was designed to break backwards compatibility for 
the sake of "cleaning up" the language. And even there, the changes were very 
conservative.


If there is every going to be a similar 3.x -> 4.x transition, and there may 
not be, it will probably be 10 years away.


Python is a lot more mature now, and consequently the costs of breaking 
backwards compatibility is much greater, particularly when it comes to 
language features like % rather than modules. After all, it is easy for Python 
users to take a copy of a depreciated module and keep using it, but it's very 
difficult for them to fork Python if a language feature is removed.





--
Steven

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-25 Thread Martin v. Löwis 
> I find that strange, especially for an expert Python dev. I, a newbie,
> find it far friendlier (and easier for a new programmer to grasp).
> Maybe it's because I use it all the time, and you don't?

That is most likely the case. You learn by practice. For that very
reason, the claim "and easier for a new programmer to grasp" is
difficult to prove. It was easier for *you*, since you started using
it, and then kept using it. I don't recall any particular obstacles
learning % formatting (even though I did for C, not for C++).
Generalizing that it is *easier* is invalid: you just didn't try
learning that instead first, and now you can't go back in a state
where either are new to you.

C++ is very similar here: they also introduced a new way of output
(iostreams, and << overloading). I used that for a couple of years,
primarily because people said that printf is "bad" and "not object-
oriented". I then recognized that there is nothing wrong with printf
per so, and would avoid std::cout in C++ these days, in favor of
std::printf (yes, I know that it does have an issue with type safety).

So I think we really should fight the impression that % formatting
in Python is "bad", "deprecated", or "old-style". Having both
may be considered a slight violation of the Zen, however, I would
claim that neither formatting API are that obvious - AFAIR, the
biggest hurdle in learning printf was to understand the notion
of "placeholder", which I think is the reason why people are coming
up with so many templating systems (templating isn't "obvious").

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-25 Thread INADA Naoki 
I don't feel "similar to other language" is not enough reason for
builtins violates the Zen.

Violating the Zen by standard library like `getopt` for compatibility to
other language or API is good.
So, I prefer moving %-style format from builtin str to function in string
module in Python 4.

On Sat, Feb 25, 2012 at 7:20 PM, "Martin v. Löwis"  wrote:
>> I find that strange, especially for an expert Python dev. I, a newbie,
>> find it far friendlier (and easier for a new programmer to grasp).
>> Maybe it's because I use it all the time, and you don't?
>
> That is most likely the case. You learn by practice. For that very
> reason, the claim "and easier for a new programmer to grasp" is
> difficult to prove. It was easier for *you*, since you started using
> it, and then kept using it. I don't recall any particular obstacles
> learning % formatting (even though I did for C, not for C++).
> Generalizing that it is *easier* is invalid: you just didn't try
> learning that instead first, and now you can't go back in a state
> where either are new to you.
>
> C++ is very similar here: they also introduced a new way of output
> (iostreams, and << overloading). I used that for a couple of years,
> primarily because people said that printf is "bad" and "not object-
> oriented". I then recognized that there is nothing wrong with printf
> per so, and would avoid std::cout in C++ these days, in favor of
> std::printf (yes, I know that it does have an issue with type safety).
>
> So I think we really should fight the impression that % formatting
> in Python is "bad", "deprecated", or "old-style". Having both
> may be considered a slight violation of the Zen, however, I would
> claim that neither formatting API are that obvious - AFAIR, the
> biggest hurdle in learning printf was to understand the notion
> of "placeholder", which I think is the reason why people are coming
> up with so many templating systems (templating isn't "obvious").
>
> Regards,
> Martin
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com



-- 
INADA Naoki  
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-25 Thread Tshepang Lekhonkhobe 
On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis"  wrote:
>> I find that strange, especially for an expert Python dev. I, a newbie,
>> find it far friendlier (and easier for a new programmer to grasp).
>> Maybe it's because I use it all the time, and you don't?
>
> That is most likely the case. You learn by practice. For that very
> reason, the claim "and easier for a new programmer to grasp" is
> difficult to prove. It was easier for *you*, since you started using
> it, and then kept using it. I don't recall any particular obstacles
> learning % formatting (even though I did for C, not for C++).
> Generalizing that it is *easier* is invalid: you just didn't try
> learning that instead first, and now you can't go back in a state
> where either are new to you.

When I started using Python, Advanced format wasn't yet available, so
I was forced to use Old style format. It's not a big issue, especially
since I had also used C before then. It's just that when Advanced
format was introduced, I fell for it, mainly because I found it more
readable (also see the sort of power Nick displayed earlier in this
thread) not to mention elegant. For that reason, I would recommend any
new Python programmer to ignore Old style altogether. That includes
those with C background.

PS: By newbie, I meant that I'm at the low ranks (at least as compared
to you), not that I only started using Python last year. Sorry for the
noise.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-25 Thread Mark Lawrence 

On 25/02/2012 05:55, Nick Coghlan wrote:

On Sat, Feb 25, 2012 at 10:23 AM, Mark Lawrence  wrote:



Quoting the docs http://docs.python.org/py3k/library/stdtypes.html

4.6.2. Old String Formatting Operations

Note

The formatting operations described here are obsolete and may go away in
future versions of Python. Use the new String Formatting in new code.



I think this is daft because all of the code has to be supported for the ten
years that MVL has suggested.


Indeed, that note was written before we decided that getting rid of
"%" formatting altogether would be a bad idea.

It would be better to update it to say something like:

"The formatting operations described here are modelled on C's printf()
syntax. They only support formatting of certain builtin types, and the
use of a binary operator means that care may be needed in order to
format tuples and dictionaries correctly. As the new string formatting
syntax is more powerful, flexible, extensible and handles tuples and
dictionaries naturally, it is recommended for new code. However, there
are no current plans to deprecate printf-style formatting."

Cheers,
Nick.



That's fine by me, it'll save me changing my own code. I'll put this on 
the issue tracker if you want, but after the pressing needs of the bar 
and 6 Nations rugby :)


--
Cheers.

Mark Lawrence.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

2012-02-25 Thread Zachary Ware 
Quick disclaimer: this is the first time I've replied on any Python list,
and thus am not entirely sure what I'm doing. Hopefully this message goes
as expected :)

Anyhow; I have to say I like Nick's idea put forth in PEP 413, but I agree
that the extra versioning info could get pretty awkward. Therefore, why not
just make stdlib upgrades part of the regular maintenance releases? As long
as there is absolutely no change in usage from (for example) 3.3.0 to
3.3.1, what's wrong with adding new (stdlib) features in 3.3.1?

Alternately, if we wanted to preserve Nick's thoughts on separate versions
with and without the stdlib upgrades, why not just make them 3.3.1 and
3.3.2, bringing us up to around 3.3.6 at 3.4.0 release? We could take a(n
old) page from Linux development's book and make the oddness/evenness of
the third number meaningful; say odds have stdlib upgrades, evens are
strictly maintenance (or vice versa).

My apologies for the noise if these ideas have been shot down elsewhere
already, but I hadn't seen it so I thought I'd stick my head in for a bit :)

Regards,
Zach Ware

On Feb 25, 2012 2:50 AM, "Nick Coghlan"  wrote:
>
> On Sat, Feb 25, 2012 at 4:59 AM, Brett Cannon  wrote:
> > On Fri, Feb 24, 2012 at 13:23, Georg Brandl  wrote:
> >> Am 24.02.2012 18:46, schrieb Antoine Pitrou:
> >> > Overall, I like the principle of this PEP, but I really dislike the
> >> > dual version numbering it introduces. Such a numbering scheme will be
> >> > cryptic and awkward for anyone but Python specialists.
> >>
> >> I agree.
> >
> > Ditto.
>
> And, in contrast, I believe that the free-wheeling minor version
> number proposed in PEP 407 is a train wreck and PR disaster waiting to
> happen. I find it interesting that we can so readily agree that using
> the major version number in any way is impossible due to the ongoing
> Python 2 -> 3 transition, yet I get so much pushback on the idea that
> messing with the implications of changing the *minor* version number
> will unnecessarily confuse or upset users.
>
> I spent quite a bit of time thinking about the ways people *use* the
> CPython version number, and it switched me from mildly preferring a
> separate version number for the standard library to being a strong
> *opponent* of increasing the rate of change for the minor version
> number. Anyway, the PEP now describes the user scenarios that
> convinced me that a separate version number for the standard library
> was the right way to go:
> http://www.python.org/dev/peps/pep-0413/#user-scenarios
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

2012-02-25 Thread Eric V. Smith 
On 2/25/2012 11:18 AM, Zachary Ware wrote:
> Anyhow; I have to say I like Nick's idea put forth in PEP 413, but I
> agree that the extra versioning info could get pretty awkward.
> Therefore, why not just make stdlib upgrades part of the regular
> maintenance releases? As long as there is absolutely no change in usage
> from (for example) 3.3.0 to 3.3.1, what's wrong with adding new (stdlib)
> features in 3.3.1?

The problem is that you can't say "my code works on Python 3.3". You now
have to specify the micro version number as well: "my code works on
Python 3.3.1+". We've made this mistake before; I can't see it happening
again.

Eric.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

2012-02-25 Thread Antoine Pitrou 
On Sat, 25 Feb 2012 11:24:47 -0500
"Eric V. Smith"  wrote:
> On 2/25/2012 11:18 AM, Zachary Ware wrote:
> > Anyhow; I have to say I like Nick's idea put forth in PEP 413, but I
> > agree that the extra versioning info could get pretty awkward.
> > Therefore, why not just make stdlib upgrades part of the regular
> > maintenance releases? As long as there is absolutely no change in usage
> > from (for example) 3.3.0 to 3.3.1, what's wrong with adding new (stdlib)
> > features in 3.3.1?
> 
> The problem is that you can't say "my code works on Python 3.3". You now
> have to specify the micro version number as well: "my code works on
> Python 3.3.1+". We've made this mistake before; I can't see it happening
> again.

I don't see how it's a mistake. It's only a mistake if it breaks the
convention on version numbers, which is precisely what we are
discussing to change.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

2012-02-25 Thread Antoine Pitrou 
On Fri, 24 Feb 2012 19:23:36 +0100
Georg Brandl  wrote:
> 
> > I also think the branches and releases management should be even
> > simpler:
> > 
> > - 2.7: as today
> > - 3.3: bug fixes + stdlib enhancements
> > - default: language enhancements / ABI-breaking changes
> > 
> > Every 6 months, a new stdlib + bugfix release would be cut (3.3.1,
> > 3.3.2, etc.), while language enhancement releases (3.4, 3.5...) would
> > still happen every 18 months.
> 
> Sorry, I don't think that's feasible at all.  For one, it removes the
> possibility to target a stable set of features for a longer time.

Why does it? You can target the 3.3.0 set of features and be
(reasonably) confident that your code will still work with 3.3.1.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

2012-02-25 Thread Georg Brandl 
On 02/25/2012 05:55 PM, Antoine Pitrou wrote:
> On Fri, 24 Feb 2012 19:23:36 +0100
> Georg Brandl  wrote:
>> 
>> > I also think the branches and releases management should be even
>> > simpler:
>> > 
>> > - 2.7: as today
>> > - 3.3: bug fixes + stdlib enhancements
>> > - default: language enhancements / ABI-breaking changes
>> > 
>> > Every 6 months, a new stdlib + bugfix release would be cut (3.3.1,
>> > 3.3.2, etc.), while language enhancement releases (3.4, 3.5...) would
>> > still happen every 18 months.
>> 
>> Sorry, I don't think that's feasible at all.  For one, it removes the
>> possibility to target a stable set of features for a longer time.
> 
> Why does it? You can target the 3.3.0 set of features and be
> (reasonably) confident that your code will still work with 3.3.1.

Yes, but anybody developing for 3.3.1 will have to specify "3.3.1+".
Which is kind of defeating the point of giving them micro versions
at all.

Frankly, the longer we are discussing about this, the more I get the
impression that all of the different proposed changes will result in
grievous mental confusion to the Great British Public^W^W^W Python
community.

Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

2012-02-25 Thread Eric V. Smith 
On 2/25/2012 11:50 AM, Antoine Pitrou wrote:
>> The problem is that you can't say "my code works on Python 3.3". You now
>> have to specify the micro version number as well: "my code works on
>> Python 3.3.1+". We've made this mistake before; I can't see it happening
>> again.
> 
> I don't see how it's a mistake. It's only a mistake if it breaks the
> convention on version numbers, which is precisely what we are
> discussing to change.

I was thinking of language changes, so maybe it doesn't apply to this
discussion. I thought there was some non-trivial addition to the
language in a micro release, but searching for it I don't come up with
anything. Maybe it was adding True and False in 2.2.1.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

2012-02-25 Thread Antoine Pitrou 
On Sat, 25 Feb 2012 18:21:40 +0100
Georg Brandl  wrote:
> 
> Yes, but anybody developing for 3.3.1 will have to specify "3.3.1+".
> Which is kind of defeating the point of giving them micro versions
> at all.
> 
> Frankly, the longer we are discussing about this, the more I get the
> impression that all of the different proposed changes will result in
> grievous mental confusion to the Great British Public^W^W^W Python
> community.

Well, the main reason we are discussing about this is that there is
some opposition to making the release schedule faster, which is the
simple and obvious solution.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASED] Release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3

2012-02-25 Thread Benjamin Peterson 
We're pleased to announce the immediate availability of release candidates for
Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 . The main impetus for these releases is
fixing a security issue in Python's hash based types, dict and set, as described
below. Python 2.7.3 and 3.2.3 include the security patch and the normal set of
bug fixes. Since Python 2.6 and 3.1 are maintained only for security issues,
2.6.8 and 3.1.5 contain only various security patches.

The security issue exploits Python's dict and set implementations. Carefully
crafted input can lead to extremely long computation times and denials of
service. [1] Python dict and set types use hash tables to provide amortized
constant time operations. Hash tables require a well-distributed hash function
to spread data evenly across the hash table. The security issue is that an
attacker could compute thousands of keys with colliding hashes; this causes
quadratic algorithmic complexity when the hash table is constructed. To
alleviate the problem, the new releases add randomization to the hashing of
Python's string types (bytes/str in Python 3 and str/unicode in Python 2),
datetime.date, and datetime.datetime. This prevents an attacker from computing
colliding keys of these types without access to the Python process.

Hash randomization causes the iteration order of dicts and sets to be
unpredictable and differ across Python runs. Python has never guaranteed
iteration order of keys in a dict or set, and applications are advised to never
rely on it. Historically, dict iteration order has not changed very often across
releases and has always remained consistent between successive executions of
Python. Thus, some existing applications may be relying on dict or set ordering.
Because of this and the fact that many Python applications which don't accept
untrusted input are not vulnerable to this attack, in all stable Python releases
mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT. There are two ways to
enable it. The -R commandline option can be passed to the python executable. It
can also be enabled by setting an environmental variable PYTHONHASHSEED to
"random". (Other values are accepted, too; pass -h to python for complete
description.)

More details about the issue and the patch can be found in the oCERT advisory
[1] and the Python bug tracker [2].

These releases are releases candidates and thus not recommended for production
use. Please test your applications and libraries with them, and report any bugs
you encounter. We are especially interested in any buggy behavior observed using
hash randomization. Excepting major calamity, final versions should appear after
several weeks.

Downloads are at

http://python.org/download/releases/2.6.8/
http://python.org/download/releases/2.7.3/
http://python.org/download/releases/3.1.5/
http://python.org/download/releases/3.2.3/

Please test these candidates and report bugs to

http://bugs.python.org/

With regards,
The Python release team
Barry Warsaw (2.6), Georg Brandl (3.2), Benjamin Peterson (2.7 and 3.1)

[1] http://www.ocert.org/advisories/ocert-2011-003.html
[2] http://bugs.python.org/issue13703
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-25 Thread Mark Lawrence 

On 25/02/2012 13:13, Mark Lawrence wrote:

On 25/02/2012 05:55, Nick Coghlan wrote:

On Sat, Feb 25, 2012 at 10:23 AM, Mark
Lawrence wrote:



Quoting the docs http://docs.python.org/py3k/library/stdtypes.html

4.6.2. Old String Formatting Operations

Note

The formatting operations described here are obsolete and may go away in
future versions of Python. Use the new String Formatting in new code.



I think this is daft because all of the code has to be supported for
the ten
years that MVL has suggested.


Indeed, that note was written before we decided that getting rid of
"%" formatting altogether would be a bad idea.

It would be better to update it to say something like:

"The formatting operations described here are modelled on C's printf()
syntax. They only support formatting of certain builtin types, and the
use of a binary operator means that care may be needed in order to
format tuples and dictionaries correctly. As the new string formatting
syntax is more powerful, flexible, extensible and handles tuples and
dictionaries naturally, it is recommended for new code. However, there
are no current plans to deprecate printf-style formatting."

Cheers,
Nick.



That's fine by me, it'll save me changing my own code. I'll put this on
the issue tracker if you want, but after the pressing needs of the bar
and 6 Nations rugby :)



I would raise this on the issue tracker but it won't let me login. 
Guess I'm not wanted. :(


--
Cheers.

Mark Lawrence.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-25 Thread Armin Ronacher 
Hi,

I just uploaded PEP 414 which proposes am optional 'u' prefix for string
literals for Python 3.

You can read the PEP online: http://www.python.org/dev/peps/pep-0414/

This is a followup to the discussion about this topic here on the
mailinglist and on twitter/IRC over the last few weeks.


Regards,
Armin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-25 Thread Mark Lawrence 

On 25/02/2012 20:16, Mark Lawrence wrote:

On 25/02/2012 13:13, Mark Lawrence wrote:

On 25/02/2012 05:55, Nick Coghlan wrote:

On Sat, Feb 25, 2012 at 10:23 AM, Mark
Lawrence wrote:



Quoting the docs http://docs.python.org/py3k/library/stdtypes.html

4.6.2. Old String Formatting Operations

Note

The formatting operations described here are obsolete and may go
away in
future versions of Python. Use the new String Formatting in new code.



I think this is daft because all of the code has to be supported for
the ten
years that MVL has suggested.


Indeed, that note was written before we decided that getting rid of
"%" formatting altogether would be a bad idea.

It would be better to update it to say something like:

"The formatting operations described here are modelled on C's printf()
syntax. They only support formatting of certain builtin types, and the
use of a binary operator means that care may be needed in order to
format tuples and dictionaries correctly. As the new string formatting
syntax is more powerful, flexible, extensible and handles tuples and
dictionaries naturally, it is recommended for new code. However, there
are no current plans to deprecate printf-style formatting."

Cheers,
Nick.



That's fine by me, it'll save me changing my own code. I'll put this on
the issue tracker if you want, but after the pressing needs of the bar
and 6 Nations rugby :)



I would raise this on the issue tracker but it won't let me login. Guess
I'm not wanted. :(



But there's more than one way of skinning a cat.
http://bugs.python.org/issue14123

--
Cheers.

Mark Lawrence.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

2012-02-25 Thread Barry Warsaw 
On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote:

>* Improve datetime.datetime objects so they support nanosecond resolution,
>   in such a way that it's 100% painless to make them even more precise in
>   the future.

+1

>* Add support to datetime objects that allows adding and subtracting ints
>   and floats as seconds.  This behavior is controllable with a flag on the
>   object--by default this behavior is off.

Why conditionalize this behavior?  It should either be enabled or not, but
making it switchable on a per-object basis seems like asking for trouble.

>* Support accepting naive datetime.datetime objects in all functions that
>   accept a timestamp in os (utime etc).

+1

>* Change the result of os.stat to be a custom class rather than a
>   PyStructSequence.  Support the sequence protocol on the custom class but
>   mark it PendingDeprecation, to be removed completely in 3.5.  (I can't
>   take credit for this idea; MvL suggested it to me once while we were
>   talking about this issue.  Now that the os.stat object has named fields,
>   who uses the struct unpacking anymore?)

+1

>* Add support for setting "stat_float_times=2" (or perhaps
>   "stat_float_times=datetime.datetime" ?) to enable returning st_[acm]time as
>   naive datetime.datetime objects--specifically, ones that allow addition and
>   subtraction of ints and floats.  The value would be similar to calling
>   datetime.datetime.fromdatetime() on the current float timestamp, but
>   would preserve all available precision.

I personally don't much like the global state represented by
os.stat_float_times() in the first place.  Even though it also could be
considered somewhat un-Pythonthic, I think it probably would have been better
to accept an optional argument in os.stat() to determine the return value.  Or
maybe it would have been more acceptable to have os.stat(), os.stat_float(),
and os.stat_datetime() methods.

>* Add a new parameter to functions that produce stat-like timestamps to
>   explicitly specify the type of the timestamps (float or datetime),
>   as proposed in PEP 410.

+1

>I disagree with PEP 410's conclusions about the suitability of datetime as
>a timestamp object.  I think "naive" datetime objects are a perfect fit.
>Specficially addressing PEP 410's concerns:
>
>   * I don't propose doing anything about the other functions that have no
> explicit start time; I'm only proposing changing the functions that deal
> with timestamps.  (Perhaps the right thing for epoch-less times like
> time.clock would be timedelta?  But I think we can table this discussion
> for now.)

+1, and yeah, I think we've had general agreement about using timedeltas for
epoch-less times.

>   * "You can't compare naive and non-naive datetimes."  So what?  The
> existing timestamp from os.stat is a float, and you can't compare floats
> and non-naive datetimes.  How is this an issue?

Exactly.

>Perhaps someone else can propose something even better,

If we really feel like we need to make a change to support higher resolution
timestamps, this comes pretty darn close to what I'd like to see.

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing an alternative to PEP 410

2012-02-25 Thread Guido van Rossum 
On Sat, Feb 25, 2012 at 1:31 PM, Barry Warsaw  wrote:
> On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote:
>
>>* Improve datetime.datetime objects so they support nanosecond resolution,
>>   in such a way that it's 100% painless to make them even more precise in
>>   the future.
>
> +1

And how would you do that? Given the way the API currently works you
pretty much have to add a separate field 'nanosecond' with a range of
0-999, leaving the microseconds field the same. (There are no
redundant fields.) This is possible but makes it quite awkward by the
time we've added picosecond and femtosecond.

>>* Add support to datetime objects that allows adding and subtracting ints
>>   and floats as seconds.  This behavior is controllable with a flag on the
>>   object--by default this behavior is off.
>
> Why conditionalize this behavior?  It should either be enabled or not, but
> making it switchable on a per-object basis seems like asking for trouble.

I am guessing that Larry isn't convinced that this is always a good
idea, but I agree with Barry that making it conditional is just too
complex.

>>* Support accepting naive datetime.datetime objects in all functions that
>>   accept a timestamp in os (utime etc).
>
> +1

What timezone would it assume? Timestamps are traditionally linked to
UTC -- but naive timestamps are most frequently used for local time.
Local time is awkward due to the ambiguities around DST transitions.

I do think we should support APIs for going back and forth between
timezone-aware datetime and timestamps.

>>* Change the result of os.stat to be a custom class rather than a
>>   PyStructSequence.  Support the sequence protocol on the custom class but
>>   mark it PendingDeprecation, to be removed completely in 3.5.  (I can't
>>   take credit for this idea; MvL suggested it to me once while we were
>>   talking about this issue.  Now that the os.stat object has named fields,
>>   who uses the struct unpacking anymore?)
>
> +1

Yeah, the sequence protocol is outdated here.

Would this be a mutable or an immutable object?

>>* Add support for setting "stat_float_times=2" (or perhaps
>>   "stat_float_times=datetime.datetime" ?) to enable returning st_[acm]time as
>>   naive datetime.datetime objects--specifically, ones that allow addition and
>>   subtraction of ints and floats.  The value would be similar to calling
>>   datetime.datetime.fromdatetime() on the current float timestamp, but
>>   would preserve all available precision.
>
> I personally don't much like the global state represented by
> os.stat_float_times() in the first place.

Agreed. We should just deprecate stat_float_times().

> Even though it also could be
> considered somewhat un-Pythonthic, I think it probably would have been better
> to accept an optional argument in os.stat() to determine the return value.

I still really don't like this.

> Or maybe it would have been more acceptable to have os.stat(), 
>os.stat_float(),
> and os.stat_datetime() methods.

But I also don't like a proliferation of functions, especially since
there are already so many stat() functions: stat(), fstat(),
fstatat().

My proposal: add extra fields that represent the time in different
types. E.g. st_atime_nsec could be an integer expressing the entire
timestamp in nanoseconds; st_atime_decimal could give as much
precision as happens to be available as a Decimal; st_atime_datetime
could be a UTC-based datetime; and in the future we could have other
forms. Plain st_atime would be a float. (It can change if and when the
default floating point type changes.)

We could make these fields lazily computed so that if you never touch
st_atime_decimal, the decimal module doesn't get loaded. (It would be
awkward if "import os" would imply "import decimal", since the latter
is huge.)

>>* Add a new parameter to functions that produce stat-like timestamps to
>>   explicitly specify the type of the timestamps (float or datetime),
>>   as proposed in PEP 410.
>
> +1

No.

>>I disagree with PEP 410's conclusions about the suitability of datetime as
>>a timestamp object.  I think "naive" datetime objects are a perfect fit.
>>Specficially addressing PEP 410's concerns:
>>
>>   * I don't propose doing anything about the other functions that have no
>>     explicit start time; I'm only proposing changing the functions that deal
>>     with timestamps.  (Perhaps the right thing for epoch-less times like
>>     time.clock would be timedelta?  But I think we can table this discussion
>>     for now.)
>
> +1, and yeah, I think we've had general agreement about using timedeltas for
> epoch-less times.

Scratch that, *I* don't agree. timedelta is a pretty clumsy type to
use. Have you ever tried to compute the number of seconds between two
datetimes? You can't just use the .seconds field, you have to combine
the .days and .seconds fields. And negative timedeltas are even harder
due to the requirement that seconds and microseconds are never
negative; e.g -1 second is rep

[Python-Dev] Versioning proposal: syntax.stdlib.bugfix

2012-02-25 Thread Terry Reedy 
We have two similar proposals, PEPs 407 and 413, to speed up the release 
of at least library changes. To me, both have major problems with 
version numbering.


I think the underlying problem is starting with a long-term fixed 
leading '3', which conveys no information about current and future 
changes (at least for another decade).


So I propose for consideration that we use the first digit to indicate a 
version of core python with fixed grammar/syntax and corresponding 
semantics. I would have this be stable for at least two years. It seems 
that most current syntax proposals amount to duplication of current 
function to suite someone's or some people's stylistic preference. My 
current view is that current syntax in mostly good enough, the 
implementation thereof is close to bug-free, and we should think 
carefully about changes.


We could then use the second digit to indicate library version. The .0 
library version would be for a long-term support version. The library 
version could change every six months, but I would not necessarily fix 
it at any particular interval. If we have some important addition or 
upgrade at four months, release it. If we need another month to include 
an important change, perhaps wait.


The third digit would be for initial (.0) and bugfix releases, as at 
present. Non .0 bugfix releases would mostly be for x.0 long-term 
syntax+library versions. x.(y!=0).0 library-change-only releases would 
only get x.(y!=0).1 bugfix releases on an 'emergency' basis.


How this would work:

Instead of 3.3.0, release 4.0.0. That would be followed by 4.0.1, 4.0.2, 
etc, bugfixes, however often we feel like it, until 5.0.0 is released.


4.0.0 would also be followed by 4.1.0 with updated stdlib in about 6 
months, then barring mistakes, 4.2.0, etc, again until 5.0.0.


A variation of this proposal would be to prefix '3.' to core.lib.fix. I 
disfavor that for 3 reasons.
1. It is not needed to indicate 'not Python 2' as *any* leading digit 
greater than 2 says the same.

2. It makes for a more awkward 4 level number.
3. It presupposes a 3 to 4 transition something like the 2 to 3 
transition. However, I am dubious about for more than one reason 
(another topic for another post).


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Rejecting PEP 410 (Use decimal.Decimal type for timestamps)

2012-02-25 Thread Guido van Rossum 
After an off-list discussion with Victor I have decided to reject PEP
410. Here are my reasons for rejecting the PEP. (Someone please copy
this to the PEP or reference this message in the archives on
mail.python.org.)

1. I have a general dislike of APIs that take a flag parameter which
modifies the return type. But I also don't like having to add variants
that return Decimal for over a dozen API functions (stat(), fstat(),
etc.). I really think that this PEP would add a lot of complexity that
we don't need.

2. The Decimal type is somewhat awkward to use; it doesn't mix with
floats, there's a context that sets things like precision and
rounding, it's still a floating point type that may lose precision
(something which many people don't get when they first see it).

3. There are *very* few clocks in existance (if any) that actually
measure time with more than 56 bits of accuracy. Sure, for short time
periods we can measure nanoseconds. But a Python (64-bit) float can
represent quite a large number of nanoseconds exactly (many millions
of seconds), so if you're using some kind of real-time timer that
reset e.g. at the start of the current process you should be fine
using a float to represent the time with great precision and accuracy.
On the other hand, if you're measuring the time of day expressed in
seconds (and fractions) since 1/1/1970, you should consider yourself
lucky if your clock is accurate within 1 second. (Especially since
POSIX systems aren't allowed to admit the existence of leap seconds in
their timestamps -- around a leap second you must adjust your clock,
either gradually or abruptly.) I'll give you that some people might
have clocks accurate to a microsecond. Such timestamps can be
represented exactly as floats (at least until some point in the very
distant future, when hopefully we'll have 128-bit floats).

4. I don't expect that timestamps with even greater precision than
nanoseconds will ever become fashionable. Given that light travels
about 30 cm in a nanosecond, there's not much use for more accurate
time measurements in daily life. Given relativity theory, at such a
timescale simultaneity of events is iffy at best.

5. I see only one real use case for nanosecond precision: faithful
copying of the mtime/atime recorded by filesystems, in cases where the
filesystem (like e.g. ext4) records these times with nanosecond
precision. Even if such timestamps can't be trusted to be accurate,
converting them to floats and back loses precision, and verification
using tools not written in Python will flag the difference. But for
this specific use case a much simpler set of API changes will suffice;
only os.stat() and os.utime() need to change slightly (and variants of
os.stat() like os.fstat()).

6. If you worry about systems where float has fewer bits: I don't
think there are any relevant systems that have both a smaller float
type and nanosecond clocks.

So far the rejection note.

As to the changes alluded to in #5: Let os.stat() and friends return
extra fields st_atime_ns (etc.) that give the timestamps in
nanoseconds as a Python (long) integer, such that e.g. (in close
approximation) st_atime == st_atime_ns * 1e-9. Let os.utime() take an
optional keyword argument ns=(atime_ns, mtime_ns). Details of the
actual design of this API, such as the actual field and parameter
names, may change; this is just a suggestion. We don't need a PEP for
this proposal; we can just open a tracker issue and hash out the
details during the code review.

I'm also in favor of getting rid of os.stat_float_times(). As proposed
in another thread, we may deprecated it in 3.3 and delete it in 3.5.
I'm not excited about adding more precision to datetime and timedelta.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-25 Thread Guido van Rossum 
If this can encourage more projects to support Python 3 (even if it's
only 3.3 and later) and hence improve adoption of Python 3, I'm all
for it.

A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.

--Guido

On Sat, Feb 25, 2012 at 12:23 PM, Armin Ronacher
 wrote:
> Hi,
>
> I just uploaded PEP 414 which proposes am optional 'u' prefix for string
> literals for Python 3.
>
> You can read the PEP online: http://www.python.org/dev/peps/pep-0414/
>
> This is a followup to the discussion about this topic here on the
> mailinglist and on twitter/IRC over the last few weeks.
>
>
> Regards,
> Armin
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Versioning proposal: syntax.stdlib.bugfix

2012-02-25 Thread Matt Joiner 
Chrome does something similar. All digits keep rising in that scheme.
However in your examples you can't identify whether bug fixes are to stdlib
or interpreter?
On Feb 26, 2012 10:07 AM, "Terry Reedy"  wrote:

> We have two similar proposals, PEPs 407 and 413, to speed up the release
> of at least library changes. To me, both have major problems with version
> numbering.
>
> I think the underlying problem is starting with a long-term fixed leading
> '3', which conveys no information about current and future changes (at
> least for another decade).
>
> So I propose for consideration that we use the first digit to indicate a
> version of core python with fixed grammar/syntax and corresponding
> semantics. I would have this be stable for at least two years. It seems
> that most current syntax proposals amount to duplication of current
> function to suite someone's or some people's stylistic preference. My
> current view is that current syntax in mostly good enough, the
> implementation thereof is close to bug-free, and we should think carefully
> about changes.
>
> We could then use the second digit to indicate library version. The .0
> library version would be for a long-term support version. The library
> version could change every six months, but I would not necessarily fix it
> at any particular interval. If we have some important addition or upgrade
> at four months, release it. If we need another month to include an
> important change, perhaps wait.
>
> The third digit would be for initial (.0) and bugfix releases, as at
> present. Non .0 bugfix releases would mostly be for x.0 long-term
> syntax+library versions. x.(y!=0).0 library-change-only releases would only
> get x.(y!=0).1 bugfix releases on an 'emergency' basis.
>
> How this would work:
>
> Instead of 3.3.0, release 4.0.0. That would be followed by 4.0.1, 4.0.2,
> etc, bugfixes, however often we feel like it, until 5.0.0 is released.
>
> 4.0.0 would also be followed by 4.1.0 with updated stdlib in about 6
> months, then barring mistakes, 4.2.0, etc, again until 5.0.0.
>
> A variation of this proposal would be to prefix '3.' to core.lib.fix. I
> disfavor that for 3 reasons.
> 1. It is not needed to indicate 'not Python 2' as *any* leading digit
> greater than 2 says the same.
> 2. It makes for a more awkward 4 level number.
> 3. It presupposes a 3 to 4 transition something like the 2 to 3
> transition. However, I am dubious about for more than one reason (another
> topic for another post).
>
> --
> Terry Jan Reedy
>
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> anacrolix%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 413 updated (with improved rationale and simpler stdlib versioning scheme)

2012-02-25 Thread Nick Coghlan 
After working through some additional scenarios (primarily the
question of handling security fixes), I have simplified the proposed
versioning scheme in PEP 413.

New version included below, or you can read the nicely formatted
version: http://www.python.org/dev/peps/pep-0413/

==

PEP: 413
Title: Faster evolution of the Python Standard Library
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan 
Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 2012-02-24
Post-History: 2012-02-24, 2012-02-25
Resolution: TBD


Abstract


This PEP proposes the adoption of a separate versioning scheme for the
standard library (distinct from, but coupled to, the existing language
versioning scheme) that allows accelerated releases of the Python standard
library, while maintaining (or even slowing down) the current rate of
change in the core language definition.

Like PEP 407, it aims to adjust the current balance between measured
change that allows the broader community time to adapt and being able to
keep pace with external influences that evolve more rapidly than the current
release cycle can handle (this problem is particularly notable for
standard library elements that relate to web technologies).

However, it's more conservative in its aims than PEP 407, seeking to
restrict the increased pace of development to builtin and standard library
interfaces, without affecting the rate of change for other elements such
as the language syntax and version numbering as well as the CPython
binary API and bytecode format.


Rationale
=

To quote the PEP 407 abstract:

Finding a release cycle for an open-source project is a delicate exercise
in managing mutually contradicting constraints: developer manpower,
availability of release management volunteers, ease of maintenance for
users and third-party packagers, quick availability of new features (and
behavioural changes), availability of bug fixes without pulling in new
features or behavioural changes.

The current release cycle errs on the conservative side. It is adequate
for people who value stability over reactivity. This PEP is an attempt to
keep the stability that has become a Python trademark, while offering a
more fluid release of features, by introducing the notion of long-term
support versions.

I agree with the PEP 407 authors that the current release cycle of the
*standard library* is too slow to effectively cope with the pace of change
in some key programming areas (specifically, web protocols and related
technologies, including databases, templating and serialisation formats).

However, I have written this competing PEP because I believe that the
approach proposed in PEP 407 of offering full, potentially binary
incompatible releases of CPython every 6 months places too great a burden
on the wider Python ecosystem.

Under the current CPython release cycle, distributors of key binary
extensions will often support Python releases even after the CPython branches
enter "security fix only" mode (for example, Twisted currently ships binaries
for 2.5, 2.6 and 2.7, NumPy and SciPy suport those 3 along with 3.1 and 3.2,
PyGame adds a 2.4 binary release, wxPython provides both 32-bit and 64-bit
binaries for 2.6 and 2.7, etc).

If CPython were to triple (or more) its rate of releases, the developers of
those libraries (many of which are even more resource starved than CPython)
would face an unpalatable choice: either adopt the faster release cycle
themselves (up to 18 simultaneous binary releases for PyGame!), drop
older Python versions more quickly, or else tell their users to stick to the
CPython LTS releases (thus defeating the entire point of speeding up the
CPython release cycle in the first place).

Similarly, many support tools for Python (e.g. syntax highlighters) can take
quite some time to catch up with language level changes.

At a cultural level, the Python community is also accustomed to a certain
meaning for Python version numbers - they're linked to deprecation periods,
support periods, all sorts of things. PEP 407 proposes that collective
knowledge all be swept aside, without offering a compelling rationale for why
such a course of action is actually *necessary* (aside from, perhaps, making
the lives of the CPython core developers a little easier at the expense of
everyone else).

However, if we go back to the primary rationale for increasing the pace of
change (i.e. more timely support for web protocols and related technologies),
we can note that those only require *standard library* changes. That means
many (perhaps even most) of the negative effects on the wider community can
be avoided by explicitly limiting which parts of CPython are affected by the
new release cycle, and allowing other parts to evolve at their current, more
sedate, pace.


Proposal


This PEP proposes the introduction of a new kind of CPython release:
"standard library releases". As

Re: [Python-Dev] Versioning proposal: syntax.stdlib.bugfix

2012-02-25 Thread Nick Coghlan 
On Sun, Feb 26, 2012 at 12:05 PM, Terry Reedy  wrote:
> We have two similar proposals, PEPs 407 and 413, to speed up the release of
> at least library changes. To me, both have major problems with version
> numbering.
>
> I think the underlying problem is starting with a long-term fixed leading
> '3', which conveys no information about current and future changes (at least
> for another decade).

Correct, but the still ongoing challenges of the 2 -> 3 transition
make that approach, as logical as it may be, entirely unworkable from
a PR point of view.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-25 Thread Nick Coghlan 
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum  wrote:
> A small quibble: I'd like to see a benchmark of a 'u' function implemented in 
> C.

Even if it was quite fast, I don't think such a function would bring
the same benefits as restoring support for u'' literals.

Using myself as an example, my work projects (such as PulpDist [1])
are currently written to target Python 2.6, since that's the system
Python on RHEL 6. As a web application, PulpDist has unicode literals
*everywhere*, but (as Armin pointed out to me), turning on "from
__future__ import unicode_literals" in every file would be incorrect,
since many of them also include native strings (mostly related to
attribute names and subprocess invocation, but probably a few WSGI
related ones as well). The action-at-a-distance of that future import
can also make the code hard to read and review (in particular, a diff
doesn't tell you whether or not the future import is present in the
original file).

It's going to be quite some time before I look at porting that code to
Python 3, but, given the style of forward compatible code that I write
(e.g. "print (X)", never "print X" or " print (X, Y)"; "except A as
B:", never "except A, B:"), the lack of unicode literals in 3.x is the
only significant sticking point I expect to encounter. If 3.3+ has
Unicode literals, I expect that PulpDist *right now* would be awfully
close to being source compatible (and any other discrepancies would
just be simple fixes like adding conditional imports from new
locations).

IIRC, I've previously opposed the restoration of unicode literals as a
retrograde step. Looking at the implications for the future migration
of PulpDist has changed my mind.

Regards,
Nick.

[1] https://fedorahosted.org/pulpdist/

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Versioning proposal: syntax.stdlib.bugfix

2012-02-25 Thread Nick Coghlan 
On Sun, Feb 26, 2012 at 12:05 PM, Terry Reedy  wrote:
> I think the underlying problem is starting with a long-term fixed leading
> '3', which conveys no information about current and future changes (at least
> for another decade).

In updating PEP 413 to include an explanation for why the simple
major.minor.micro = language.stdlib.maintenance approach doesn't work
due to the ongoing 2->3 transition [1], I realised that there *is* a
way to make it work:

Instead of making 3.3 version 4.0, we make it version 33.0

That's essentially what PEP 413 currently proposes for the standard
library anyway, but it would actually work just as well for the
existing sys.version_info structure. (it would break
"sys.version_info.major == 3" checks, but such checks are badly
written)

[1] 
http://www.python.org/dev/peps/pep-0413/#why-not-use-the-major-version-number

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

2012-02-25 Thread Stefan Behnel 
Stefan Behnel, 23.02.2012 09:01:
> "Martin v. Löwis", 19.02.2012 23:24:
>>> When compiling for PyPy, Cython therefore needs a way to tell PyPy about
>>> any changes. For the tstate->curexc_* fields, there are the two functions
>>> PyErr_Fetch() and PyErr_Restore(). Could we have two similar "official"
>>> functions for the exc_* fields? Maybe PyErr_FetchLast() and
>>> PyErr_RestoreLast()?
>>
>> I wouldn't call the functions *Last, as this may cause confusion with
>> sys.last_*. I'm also unsure why the current API uses this Fetch/Restore
>> pair of functions where Fetch clears the variables. A Get/Set pair of
>> functions would be more natural, IMO (where Get returns "new"
>> references). This would give PyErr_GetExcInfo/PyErr_SetExcInfo.
> 
> Ok, I added a tracker ticket and I'm working on a patch.
> 
> http://bugs.python.org/issue14098

The patch is attached to the ticket, including documentation and test. I'd
be happy if someone could review it and apply it.

Thanks!

Stefan

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com