On Sat, Feb 25, 2012 at 1:32 PM, Matt Joiner wrote:
> Evidently some modules have to ship with core if they are required (sys),or
> expose internals (os, gc). Others are clearly extras, (async{ore,hat},
> subprocess, unittest, select).
There's a whole raft of additional dependencies introduced by
On Sat, Feb 25, 2012 at 10:20 AM, wrote:
> 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.
Heh, I've switched almost entirely to .
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
Why not cut the (external) stdlib before each minor release?
Testing new language features is not the role of a public release, this is
no reason to require ownership on a module.
Evidently some modules have to ship with core if they are required (sys),or
expose internals (os, gc). Others are cle
On 2/24/2012 7:23 PM, Mark Lawrence wrote:
I think this is daft because all of the code has to be supported for
the ten years that MVL has suggested. I suggest a plan that says
something like:-
Until Python 3.5 both methods of string formatting will be supported.
In Python 3.6 the the old for
On Fri, Feb 24, 2012 at 21:08, Matt Joiner wrote:
> I think every minor release should be fully supported. The current rate of
> change is very high and there's a huge burden on implementers and
> production users to keep up, so much so that upgrading is undesirable
> except for serious enthusias
I think every minor release should be fully supported. The current rate of
change is very high and there's a huge burden on implementers and
production users to keep up, so much so that upgrading is undesirable
except for serious enthusiasts.
Include just the basics and CPython specific modules in
On Feb 24, 2012 6:26 PM, "Mark Lawrence" wrote:
>
> On 24/02/2012 21:37, "Martin v. Löwis" wrote:
>>>
>>> I was of the thought that Old String Formatting |"%s" % foo| was to be
>>> phased out by Advanced String Formatting |"{}.format(foo)|.
>>
>>
>> This is actually not the case, and never was. So
On 24/02/2012 21:37, "Martin v. Löwis" wrote:
I was of the thought that Old String Formatting |"%s" % foo| was to be
phased out by Advanced String Formatting |"{}.format(foo)|.
This is actually not the case, and never was. Some people would indeed
like to see that happen, and others are strongl
Zitat von Tshepang Lekhonkhobe :
On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" wrote:
It is a burden for some people to learn and remember the exact details
of both systems and exactly how they differ. Having both in the stdlib
hurts readability for such people. I would prefer that the std
On Feb 24, 2012, at 10:39 PM, Martin v. Löwis wrote:
>> It is a burden for some people to learn and remember the exact details
>> of both systems and exactly how they differ. Having both in the stdlib
>> hurts readability for such people. I would prefer that the stdlib only
>> used {} formatting o
On Fri, Feb 24, 2012 at 1:52 PM, Tshepang Lekhonkhobe
wrote:
> On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" wrote:
>>> It is a burden for some people to learn and remember the exact details
>>> of both systems and exactly how they differ. Having both in the stdlib
>>> hurts readability for su
On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" wrote:
>> It is a burden for some people to learn and remember the exact details
>> of both systems and exactly how they differ. Having both in the stdlib
>> hurts readability for such people. I would prefer that the stdlib only
>> used {} formattin
> I was of the thought that Old String Formatting |"%s" % foo| was to be
> phased out by Advanced String Formatting |"{}.format(foo)|.
This is actually not the case, and never was. Some people would indeed
like to see that happen, and others are strongly opposed.
As a consequence, both APIs for f
> It is a burden for some people to learn and remember the exact details
> of both systems and exactly how they differ. Having both in the stdlib
> hurts readability for such people. I would prefer that the stdlib only
> used {} formatting or if not that, that it only used the simple,
> hard-to-for
On 2/24/2012 11:41 AM, Benjamin Peterson wrote:
2012/2/24 Tshepang Lekhonkhobe:
Hi,
I was of the thought that Old String Formatting |"%s" % foo| was to be
phased out by Advanced String Formatting |"{}.format(foo)|. I however
keep seeing new code committed into the main VCS using the old style.
On Fri, Feb 24, 2012 at 13:23, Georg Brandl wrote:
> Am 24.02.2012 18:46, schrieb Antoine Pitrou:
> >
> > Hello,
> >
> > On Sat, 25 Feb 2012 03:24:27 +1000
> > Nick Coghlan wrote:
> >> To allow the PEP 407 authors to focus on making the case for doing
> >> full CPython releases every 6 months (i
Am 24.02.2012 18:46, schrieb Antoine Pitrou:
>
> Hello,
>
> On Sat, 25 Feb 2012 03:24:27 +1000
> Nick Coghlan wrote:
>> To allow the PEP 407 authors to focus on making the case for doing
>> full CPython releases every 6 months (including language spec
>> updates), I've created PEP 413 as a compe
Tshepang Lekhonkhobe wrote:
Hi,
I was of the thought that Old String Formatting |"%s" % foo| was to be
phased out by Advanced String Formatting |"{}.format(foo)|. I however
keep seeing new code committed into the main VCS using the old style.
Is this okay? Is there a policy? I ask also because I
Hello,
On Sat, 25 Feb 2012 03:24:27 +1000
Nick Coghlan wrote:
> To allow the PEP 407 authors to focus on making the case for doing
> full CPython releases every 6 months (including language spec
> updates), I've created PEP 413 as a competing proposal.
>
> It leaves the current language version
On Sat, Feb 25, 2012 at 2:41 AM, Benjamin Peterson wrote:
> 2012/2/24 Tshepang Lekhonkhobe :
>> Hi,
>>
>> I was of the thought that Old String Formatting |"%s" % foo| was to be
>> phased out by Advanced String Formatting |"{}.format(foo)|. I however
>> keep seeing new code committed into the main
To allow the PEP 407 authors to focus on making the case for doing
full CPython releases every 6 months (including language spec
updates), I've created PEP 413 as a competing proposal.
It leaves the current language versioning (and rate of change) alone,
while adding an additional date based stand
ACTIVITY SUMMARY (2012-02-17 - 2012-02-24)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3277 (+20)
closed 22611 (+44)
total 25888 (+64)
Open issues wit
2012/2/24 Tshepang Lekhonkhobe :
> Hi,
>
> I was of the thought that Old String Formatting |"%s" % foo| was to be
> phased out by Advanced String Formatting |"{}.format(foo)|. I however
> keep seeing new code committed into the main VCS using the old style.
> Is this okay? Is there a policy? I ask
Hi,
I was of the thought that Old String Formatting |"%s" % foo| was to be
phased out by Advanced String Formatting |"{}.format(foo)|. I however
keep seeing new code committed into the main VCS using the old style.
Is this okay? Is there a policy? I ask also because I expect CPython
to lead by exa
Oh sorry and thanks for the fix.
Victor
2012/2/24 Antoine Pitrou :
> On Fri, 24 Feb 2012 00:49:31 +0100
> victor.stinner wrote:
>> http://hg.python.org/cpython/rev/f89e2f4cda88
>> changeset: 75231:f89e2f4cda88
>> user: Victor Stinner
>> date: Fri Feb 24 00:37:51 2012 +0100
>> su
On Fri, 24 Feb 2012 00:49:31 +0100
victor.stinner wrote:
> http://hg.python.org/cpython/rev/f89e2f4cda88
> changeset: 75231:f89e2f4cda88
> user:Victor Stinner
> date:Fri Feb 24 00:37:51 2012 +0100
> summary:
> Issue #13706: Fix format(int, "n") for locale with non-ASCII thousa
> Unfortunately it seems to be the norm in CPython to publish almost
> everything in header files that get included in "Python.h".
In many cases, this is purely for historic reasons. In many additional
cases, it's to support fast access macros, at least in the interpreter
itself, but then also in
28 matches
Mail list logo
