On Sat, Feb 25, 2012 at 05:10, Ned Batchelder n...@nedbatchelder.com 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
On Sat, Feb 25, 2012 at 02:20, mar...@v.loewis.de wrote:
Zitat von Tshepang Lekhonkhobe tshep...@gmail.com:
On Fri, Feb 24, 2012 at 23:39, Martin v. Löwis mar...@v.loewis.de
If that issue was getting serious, I would prefer if the .format method
was deprecated, and only % formatting was kept.
On Sat, Feb 25, 2012 at 05:32, Matt Joiner anacro...@gmail.com 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
On Sat, Feb 25, 2012 at 4:59 AM, Brett Cannon br...@python.org wrote:
On Fri, Feb 24, 2012 at 13:23, Georg Brandl g.bra...@gmx.net 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.
Tshepang Lekhonkhobe wrote:
On Sat, Feb 25, 2012 at 05:10, Ned Batchelder n...@nedbatchelder.com 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
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
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,
On Sat, Feb 25, 2012 at 12:20, Martin v. Löwis mar...@v.loewis.de 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
On 25/02/2012 05:55, Nick Coghlan wrote:
On Sat, Feb 25, 2012 at 10:23 AM, Mark Lawrencebreamore...@yahoo.co.uk wrote:
quote
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
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.
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
On Sat, 25 Feb 2012 11:24:47 -0500
Eric V. Smith e...@trueblade.com 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
On Fri, 24 Feb 2012 19:23:36 +0100
Georg Brandl g.bra...@gmx.net 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
On 02/25/2012 05:55 PM, Antoine Pitrou wrote:
On Fri, 24 Feb 2012 19:23:36 +0100
Georg Brandl g.bra...@gmx.net 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 /
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
On Sat, 25 Feb 2012 18:21:40 +0100
Georg Brandl g.bra...@gmx.net 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
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
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
Lawrencebreamore...@yahoo.co.uk wrote:
quote
Quoting the docs http://docs.python.org/py3k/library/stdtypes.html
4.6.2. Old String Formatting Operations
Note
The
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.
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
Lawrencebreamore...@yahoo.co.uk wrote:
quote
Quoting the docs http://docs.python.org/py3k/library/stdtypes.html
4.6.2. Old
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
On Sat, Feb 25, 2012 at 1:31 PM, Barry Warsaw ba...@python.org 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
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
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
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
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 tjre...@udel.edu wrote:
We have two similar proposals, PEPs 407 and 413, to speed up the release
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/
On Sun, Feb 26, 2012 at 12:05 PM, Terry Reedy tjre...@udel.edu 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
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org 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
On Sun, Feb 26, 2012 at 12:05 PM, Terry Reedy tjre...@udel.edu 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
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
31 matches
Mail list logo
