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
Python-Dev@python.org
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 s
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?
___
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 wil
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 ex
> 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
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" 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
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 ve
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. The
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 absolutel
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 o
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
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 enhanceme
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
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 tha
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
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
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.
Re
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
Not
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 int
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 wo
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
ch
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 th
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
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
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 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
> '
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,
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
m
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 "offici
31 matches
Mail list logo
