Re: [Python-Dev] New shared-keys dictionary implementation (issue13903)
> 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 extension modules. I agree that moving the structures into the implementation is fine, as long as there are sufficient access functions (for dictionaries, there are plenty, of course). 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] cpython: Issue #13706: Fix format(int, "n") for locale with non-ASCII thousands separator
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 thousands > separator Can you please check the buildbots after you commit something large? This commit broke compilation under Windows. cheers 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] cpython: Issue #13706: Fix format(int, "n") for locale with non-ASCII thousands separator
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 >> summary: >> Issue #13706: Fix format(int, "n") for locale with non-ASCII thousands >> separator > > Can you please check the buildbots after you commit something large? > This commit broke compilation under Windows. ___ 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] Status regarding Old vs. Advanced String Formating
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 example.
On another note, will the old format ever be deprecated? Is there a date?
___
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/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 also because I expect CPython
> to lead by example.
Using either is fine I think. It doesn't hurt anyone to have old
string formatting around for a long time. In general, +0 for using new
string formatting.
>
> On another note, will the old format ever be deprecated? Is there a date?
I doubt it.
--
Regards,
Benjamin
___
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] Summary of Python tracker Issues
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 with patches: 1406 Issues opened (46) == #13637: binascii.a2b_* functions could accept unicode strings http://bugs.python.org/issue13637 reopened by r.david.murray #13641: decoding functions in the base64 module could accept unicode s http://bugs.python.org/issue13641 reopened by r.david.murray #14044: IncompleteRead error with urllib2 or urllib.request -- fine wi http://bugs.python.org/issue14044 opened by Alex Quinn #14046: argparse: assertion failure if optional argument has square/ro http://bugs.python.org/issue14046 opened by oxplot #14049: execfile() fails on files that use global variables inside fun http://bugs.python.org/issue14049 opened by techtonik #14050: Tutorial, list.sort() and items comparability http://bugs.python.org/issue14050 opened by sandro.tosi #14055: Implement __sizeof__ for etree Element http://bugs.python.org/issue14055 opened by loewis #14056: Misc doc changes for tarfile http://bugs.python.org/issue14056 opened by eric.araujo #14057: Speedup sysconfig startup http://bugs.python.org/issue14057 opened by haypo #14059: Implement multiprocessing.Barrier http://bugs.python.org/issue14059 opened by anacrolix #14060: Implement a CSP-style channel http://bugs.python.org/issue14060 opened by anacrolix #14061: Clean up archiving code in shutil http://bugs.python.org/issue14061 opened by eric.araujo #14062: UTF-8 Email Subject problem http://bugs.python.org/issue14062 opened by msladek #14065: Element should support cyclic GC http://bugs.python.org/issue14065 opened by loewis #14067: Avoid more stat() calls in importlib http://bugs.python.org/issue14067 opened by pitrou #14069: In extensions (?...) the lookbehind assertion cannot choose be http://bugs.python.org/issue14069 opened by py.user #14070: Idea: Add a flag to reload from source, e.g. reload(module, ig http://bugs.python.org/issue14070 opened by timClicks #14071: allow more than one hash seed per process (move _Py_HashSecret http://bugs.python.org/issue14071 opened by gregory.p.smith #14072: urlparse on tel: URI-s misses the scheme in some cases http://bugs.python.org/issue14072 opened by ivan_herman #14074: argparse does not allow nargs>1 for positional arguments but d http://bugs.python.org/issue14074 opened by tshepang #14075: argparse: unused method? http://bugs.python.org/issue14075 opened by tshepang #14076: sqlite3 module ignores placeholers in CREATE TRIGGER code http://bugs.python.org/issue14076 opened by GuGu #14078: Add 'sourceline' property to xml.etree Elements http://bugs.python.org/issue14078 opened by leonov #14080: Sporadic test_imp failure http://bugs.python.org/issue14080 opened by pitrou #14081: Allow "maxsplit" argument to str.split() to be passed as a key http://bugs.python.org/issue14081 opened by ncoghlan #14082: shutil doesn't support extended attributes http://bugs.python.org/issue14082 opened by pitrou #14085: PyUnicode_WRITE: "comparison is always true" warnings http://bugs.python.org/issue14085 opened by skrah #14087: multiprocessing.Condition.wait_for missing http://bugs.python.org/issue14087 opened by sbt #14088: sys.executable generating canonical path http://bugs.python.org/issue14088 opened by alvesjnr #14089: Patch to increase fractions lib test coverage http://bugs.python.org/issue14089 opened by Oleg.Plakhotnyuk #14092: __name__ inconsistently applied in class definition http://bugs.python.org/issue14092 opened by eukreign #14093: Mercurial version information not appearing in Windows builds http://bugs.python.org/issue14093 opened by vinay.sajip #14094: nt.realpath() should use GetFinalPathNameByHandle() when avail http://bugs.python.org/issue14094 opened by haypo #14095: type_new() removes __qualname__ from the input dictionary http://bugs.python.org/issue14095 opened by haypo #14097: Improve the "introduction" page of the tutorial http://bugs.python.org/issue14097 opened by ezio.melotti #14098: provide public C-API for reading/setting sys.exc_info() http://bugs.python.org/issue14098 opened by scoder #14099: ZipFile.open() should not reopen the underlying file http://bugs.python.org/issue14099 opened by kasal #14100: Add a missing info to PEP 393 + link from whatsnew 3.3 http://bugs.python.org/issue14100 opened by tshepang #14101: example function in tertools.count docstring is misindented http://bugs.python.org/issue14101 opened by zbysz #14102: argparse: add ability to create a man page http://bugs.python.org/issue14102 opened by Daniel.Walsh #14103: argparse: add ability to create a bash_completion script http://bugs.python.org/issue14103 opened by Daniel.Walsh #14104: Implement time.monotonic() on
[Python-Dev] PEP 413: Faster evolution of the Python Standard Library
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 standard library version number and adopting a new development workflow that will allow "standard library" releases to be made alongside each new maintenance release. PEP text is below, or you can read it online: http://www.python.org/dev/peps/pep-0413/ Cheers, Nick. 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 Resolution: TBD Abstract This PEP proposes the adoption of a new date-based 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). But, 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 pa
Re: [Python-Dev] Status regarding Old vs. Advanced String Formating
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 VCS using the old style.
>> Is this okay? Is there a policy? I ask also because I expect CPython
>> to lead by example.
>
> Using either is fine I think. It doesn't hurt anyone to have old
> string formatting around for a long time. In general, +0 for using new
> string formatting.
Yep. Also, the two can work nicely in tandem as templates for each
other that don't need tons of escaping.
>>
>> On another note, will the old format ever be deprecated? Is there a date?
>
> I doubt it.
*If* the old format were ever to be deprecated (and that's a very big
if), Python 4k would be the earliest it could happen. More likely the
old format will just hang around indefinitely, though.
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
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 versioning (and rate of change) alone, > while adding an additional date based standard library version number > and adopting a new development workflow that will allow "standard > library" releases to be made alongside each new maintenance release. 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 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. If people really want some bugfix releases without any stdlib enhancements, we have two solutions: - let them handle patch maintenance themselves - have a community-maintained bugfix branch or repo somewhere, where interested contributors can backport selected bugfixes 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] Status regarding Old vs. Advanced String Formating
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 expect CPython
to lead by example.
On another note, will the old format ever be deprecated? Is there a date?
Brett Cannon wrote:
> On Tue, Feb 22, 2011 at 10:43, Ethan Furman wrote:
>
>> Greetings!
>>
>> According to these release notes in Python 3.0, %-formatting will be
>> going away.
>>
>>
http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting
>>
>> However, I was unable to find any further evidence of actual
>> deprecation in 3.1 or 3.2... does anybody know the status of this?
>>
>
> There isn't one. =)
>
> The very long term view is for %-formatting to go away, but that's as
> far as the thinking has gone. There are currently no plans to
> introduce any deprecation warning, and I highly doubt we will even
> remove the feature in Python 3, giving you probably at least another
> decade of use at our current major version release schedule. =)
___
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
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 competing proposal. >> >> It leaves the current language versioning (and rate of change) alone, >> while adding an additional date based standard library version number >> and adopting a new development workflow that will allow "standard >> library" releases to be made alongside each new maintenance release. > > 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. > 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. In short, the only usable solution I see is PEP 407-style versioning with language changes only in LTS releases. 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
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 (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 standard library version number > >> and adopting a new development workflow that will allow "standard > >> library" releases to be made alongside each new maintenance release. > > > > 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. You could also mention that this could help other VMs by getting compatibility fixes into the stdlib faster than they do currently, letting other VMs hit minor release compat faster. > > > 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. > > In short, the only usable solution I see is PEP 407-style versioning > with language changes only in LTS releases. While I personally would rather switch to making the major version mean a language change has occurred instead of reserving it for completely backwards-incompatible language changes, I know history is going to lead people killing that idea, so I agree with Georg on using an LTS delineation for language-changing releases and keeping them patched up until the next LTS is better. IOW we cut 3.3.0 as an LTS and then have 3.4 and 3.5 only contain stdlib changes while also releasing 3.3.1 and 3.3.2 for bugfixes on 3.3. There would be no micro releases for 3.4 and 3.5 (sans an emergency brown bag release) since the next release is coming in 6 months anyway with any previous bugfixes + changes that might break compatibility with 3.3 in the stdlib. My worry with Antoine's approach is that it will cause pain for people by us mucking around with stdlib stuff that will break compatibility somehow, preventing some people from upgrading immediately, but out in the cold when it comes to bugfixes since they can't grab the next release yet. The only way for Antoine's approach to work is if we made some release count guarantee (like 3 releases) for anything that might break someone, making stdlib-only releases more accumulative then iterative. ___ 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
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.
Is this okay? Is there a policy? I ask also because I expect CPython
to lead by example.
Using either is fine I think. It doesn't hurt anyone to have old
string formatting around for a long time.
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-forget forms of % formatting (%s, %d, %f, without elaboration).
--
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
Re: [Python-Dev] Status regarding Old vs. Advanced String Formating
> 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-forget forms of % formatting (%s, %d, %f, without elaboration).
If that issue was getting serious, I would prefer if the .format method
was deprecated, and only % formatting was kept.
I doubt this is as much of an issue as you think, though.
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
> 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 formatting will coexist for a long time
to come (ten years at least); no deprecation is planned.
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
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 {} formatting or if not that, that it only used the simple,
>> hard-to-forget forms of % formatting (%s, %d, %f, without elaboration).
>
> 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? Or is this just a matter of taste?
___
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
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 such people. I would prefer that the stdlib only
>>> used {} formatting or if not that, that it only used the simple,
>>> hard-to-forget forms of % formatting (%s, %d, %f, without elaboration).
>>
>> 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? Or is this just a matter of
> taste?
It has superior features, but its current implementation is much
slower and there is a HUGE body of existing code that would need
conversion (a lot of that is automatable), including most uses of the
logging module. % formatting is also familiar to anyone who uses C
and C++ on a regular basis.
as martin said, both will exist for a long time.
-gps
___
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
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 or if not that, that it only used the simple,
>> hard-to-forget forms of % formatting (%s, %d, %f, without elaboration).
>
>If that issue was getting serious, I would prefer if the .format method
>was deprecated, and only % formatting was kept.
>
>I doubt this is as much of an issue as you think, though.
I personally prefer .format() these days, but I agree that it will be a long
time, if ever, we see one of the styles getting dropped. I don't have much of
a problem with the stdlib containing both styles as appropriate and preferred
by the maintainer, as long as the module is consistent. Also, modules which
provide a format-ish API should accept both styles, such as what logging
currently does. (It's nice that logging also accepts PEP 292 $-strings too,
don't forget about those. :)
-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] Status regarding Old vs. Advanced String Formating
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 stdlib only
used {} formatting or if not that, that it only used the simple,
hard-to-forget forms of % formatting (%s, %d, %f, without elaboration).
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.
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
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 strongly opposed.
As a consequence, both APIs for formatting will coexist for a long time
to come (ten years at least); no deprecation is planned.
Regards,
Martin
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. 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 formating style will be deprecated.
In Python 3.7 the old style is dead.
I'm fully aware that it isn't likely to be that easy, I'm simply trying
to spark ideas from the core developers and users who are in a far
better situation to judge this situation than I am.
--
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] Status regarding Old vs. Advanced String Formating
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. Some people would indeed
>> like to see that happen, and others are strongly opposed.
>>
>> As a consequence, both APIs for formatting will coexist for a long time
>> to come (ten years at least); no deprecation is planned.
>>
>> Regards,
>> Martin
>
>
>
> 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. 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 formating style will be deprecated.
> In Python 3.7 the old style is dead.
>
> I'm fully aware that it isn't likely to be that easy, I'm simply trying
to spark ideas from the core developers and users who are in a far better
situation to judge this situation than I am.
-infinity. We can't do that as outlined earlier in the thread.
___
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
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 the core release and version the stdlib separately. The stdlib should be supported such that it can be installed to an arbitrary version of Python. Better yet I'd like to see the stdlib become a list of vetted external libraries that meet some requirements on usefulness, stability and compatibility (PEP), that get cut at regular intervals. This takes the burden away from core, improves innovation, allows for different implementations, and ensures that the Python package management system is actually useful. ___ 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
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 enthusiasts. > > Include just the basics and CPython specific modules in the core release > and version the stdlib separately. The stdlib should be supported such that > it can be installed to an arbitrary version of Python. > That idea has been put forth and shot down. The stdlib has to be tied to at least some version of Python just like any other project. Plus the stdlib is where we try out new language features to make sure they make sense. Making it a separate project is not that feasible. > Better yet I'd like to see the stdlib become a list of vetted external > libraries that meet some requirements on usefulness, stability and > compatibility (PEP), that get cut at regular intervals. This takes the > burden away from core, improves innovation, allows for different > implementations, and ensures that the Python package management system is > actually useful. > That's been called a sumo release and proposed before, but no one has taken the time to do it (although the 3rd-party releases of Python somewhat take this view). Thinning out the stdlib in favour of the community providing solutions is another can of worms which does not directly impact the discussion of how to handle stdlib releases unless you are pushing to simply drop the stdlib which is not possible as Python itself depends on it. ___ 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
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 formating style will be deprecated. In Python 3.7 the old style is dead. I'm fully aware that it isn't likely to be that easy, I'm simply trying to spark ideas from the core developers and users who are in a far better situation to judge this situation than I am. I don't understand why we'd even consider getting rid of old-style formatting. Python does a great job keeping things working into the future, and there are so many features in the language and library that are there to keep old code working in spite of newer ways to accomplish the same task. Has Python *ever* removed a feature except in X.0 releases? Why are we even discussing this? Two ways to format strings is no big deal, especially considering how heavily used these tools are. And btw, if you include the almost-never-mentioned string.Template, there are at least three ways to do it, maybe more. --Ned. ___ 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
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 clearly extras, (async{ore,hat},
subprocess, unittest, select).
There are so many third party modules languishing because inferior forms
exist in the stdlib, and no centralized method for their recommendation and
discovery. Breaking out optional parts of the stdlib is an enabling step
towards addressing this. I would suggest Haskell, node.js and golang as
examples of how stdlibs are minimal enough to define basic idiomatic
interfaces but allow and encourage extension.
On Feb 25, 2012 10:53 AM, "Brett Cannon" wrote:
>
>
> 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 enthusiasts.
>>
>> Include just the basics and CPython specific modules in the core release
>> and version the stdlib separately. The stdlib should be supported such that
>> it can be installed to an arbitrary version of Python.
>>
>
> That idea has been put forth and shot down. The stdlib has to be tied to
> at least some version of Python just like any other project. Plus the
> stdlib is where we try out new language features to make sure they make
> sense. Making it a separate project is not that feasible.
>
>
>> Better yet I'd like to see the stdlib become a list of vetted external
>> libraries that meet some requirements on usefulness, stability and
>> compatibility (PEP), that get cut at regular intervals. This takes the
>> burden away from core, improves innovation, allows for different
>> implementations, and ensures that the Python package management system is
>> actually useful.
>>
>
> That's been called a sumo release and proposed before, but no one has
> taken the time to do it (although the 3rd-party releases of Python somewhat
> take this view). Thinning out the stdlib in favour of the community
> providing solutions is another can of worms which does not directly impact
> the discussion of how to handle stdlib releases unless you are pushing to
> simply drop the stdlib which is not possible as Python itself depends on it.
>
___
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
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. -- 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
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 .format() just so I never have
to worry if:
fmt % arg
should actually be written as:
fmt % (arg,)
With fmt.format(arg), the question just never comes up.
Since 90%+ of the replacement field specifiers I use are just "{}" or
"{!r}" (the format-style equivalents to "%s" and "%r" in printf-style
formatting), and most of the rest are either using field references or
just {:number_spec} (where the number formatting is the same as that
in printf-style) the complexity of the full mini-language doesn't
really come into play (although I did find use recently for several of
the features in order to emit nicely formatted data from a command
line utility).
Another *very* handy trick is "{0.attr} {0.attr2}" for concise
attribute formatting.
Really, what the new-style formatting is most lacking is a tutorial or
cookbook style reference to teach people things like:
- here's how to do basic string interpolation ("{}")
- here's how to use repr() or ascii() instead of str() ("{!r}", "{!a}")
- here's how to explicit number your fields so you can refer to the
same argument more than once ("{0}")
- here's how to name your fields so you can use keyword arguments or
format_map()
- here's how to access attributes of an object being formatted
- here's how to access individual items in a container being formatted
- here's how to do implicit string interpolation with format_map() on
locals() or vars(obj)
- here's how to align (and/or truncate) text within a field
- here's how to format numbers
- here's how to implicitly invoke strftime
And in a more advanced section:
- here's how to use __format__() to customise the formatting options
for your own class
- here's how to use string.StringFormatter to create a custom
formatting variant (e.g. one that invokes shlex.quote() on
interpolated variables by default)
Currently we point them directly at the relevant section of the
*language spec*, which is written for people trying to create
compliant formatting implementations, not anyone that just wants to
*use* the thing.
However, while I'm personally a fan of the new format() methods and
greatly prefer them to the old way of doing things, I agree it would
be a bad idea to try to *force* people to switch if they're used to
printf-style formatting and don't have any issues with it
(particularly given the current expert-friendly state of the
documentation). It's not like printf-style formatting is a security
risk or poses some kind of huge maintenance burden. I see it as
similar to the getopt/optparse/argparse situation. getopt() has value
for consistency with C's getopt() API, argparse is the current
recommended best practice, while optparse is kept around because it is
so prevalent that it isn't worth trying to remove it. Similarly,
printf-style formatting has value for its consistency with C and
deserves to be kept around due to both that and its current
prevalence.
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
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 the
build process and the regression test suite. The fact that your
"others are clearly extras" was only right for 2 out of 5 examples
doesn't fill me with confidence that you have any idea of the scale of
what you're suggesting.
But the real reason this isn't going to happen? It's an absolute ton
of work that *won't make Python better at the end*. Anyone that feels
otherwise is free to fork CPython and try it for themselves, but I
predict they will be thoroughly disappointed with the outcome. (We
moved to a DVCS in large part to make it easier for other people to
experiment with things - they don't have to ask python-dev's
permission, they can just fork, try it for themselves, and see if it
works out. If they instead want to *pay* somebody to try it on their
behalf, then they can just offer some contract work and see if they
get any takers).
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
