Python-Dev
Threads by month
- ----- 2025 -----
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
February 2013
- 103 participants
- 85 discussions

Re: [Python-Dev] [Python-checkins] peps: PEP-0427: clarify some implementation details.
by Nick Coghlan Feb. 25, 2013
by Nick Coghlan Feb. 25, 2013
Feb. 25, 2013
On Mon, Feb 25, 2013 at 12:41 PM, daniel.holth
<python-checkins(a)python.org> wrote:
> http://hg.python.org/peps/rev/7d2494f4cd0a
> changeset: 4772:7d2494f4cd0a
> user: Daniel Holth <dholth(a)fastmail.fm>
> date: Sun Feb 24 21:41:40 2013 -0500
> summary:
> PEP-0427: clarify some implementation details.
>
> Hope it's OK to clarify two details that came up during Vinay's distlib wheel
> implementation: zip directory filenames are encoded as …
[View More]utf-8, and it's nicer
> to put the .dist-info directory at the end of the archive.
It's better to announce the intended update/clarification on
python-dev first, but I agree both these adjustments are reasonable (I
don't remember if I actually said that in the distutils-sig thread).
Regards,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
[View Less]
1
0
Hello,
in August 2012 I found a DoS vulnerability in expat and XML libraries in
Python's standard library. Since then I have found several more issues.
I have been working on fixes ever since.
The README of https://pypi.python.org/pypi/defusedxml contains detailed
explanations of my research and all issues
Blog post:
http://blog.python.org/2013/02/announcing-defusedxml-fixes-for-xml.html
Hotfixes:
https://pypi.python.org/pypi/defusedxml
https://pypi.python.org/pypi/defusedexpat
…
[View More]Repositories:
https://bitbucket.org/tiran/defusedxml
https://bitbucket.org/tiran/defusedexpat
https://bitbucket.org/tiran/expat
CVE (work in progress)
CVE-2013-1664
Unrestricted entity expansion induces DoS vulnerabilities in
Python XML libraries (XML bomb)
CVE-2013-1665
External entity expansion in Python XML libraries
inflicts potential security flaws and DoS vulnerabilities
Regards,
Christian
Extract from the documentation:
Synopsis
--------
The results of an attack on a vulnerable XML library can be fairly
dramatic. With just a few hundred Bytes of XML data an attacker can
occupy several Gigabytes of memory within seconds. An attacker can also
keep CPUs busy for a long time with a small to medium size request.
Under some circumstances it is even possible to access local files on
your server, to circumvent a firewall, or to abuse services to rebound
attacks to third parties.
The attacks use and abuse less common features of XML and its parsers.
The majority of developers are unacquainted with features such as
processing instructions and entity expansions that XML inherited from
SGML. At best they know about <!DOCTYPE> from experience with HTML but
they are not aware that a document type definition (DTD) can generate an
HTTP request or load a file from the file system.
None of the issues is new. They have been known for a long time. Billion
laughs was first reported in 2003. Nevertheless some XML libraries and
applications are still vulnerable and even heavy users of XML are
surprised by these features. It's hard to say whom to blame for the
situation. It's too short sighted to shift all blame on XML parsers and
XML libraries for using insecure default settings. After all they
properly implement XML specifications. Application developers must not
rely that a library is always configured for security and potential
harmful data by default.
Attack vectors
==============
billion laughs / exponential entity expansion
---------------------------------------------
The Billion Laughs attack -- also known as exponential entity expansion
-- uses multiple levels of nested entities. The original example uses 9
levels of 10 expansions in each level to expand the string lol to a
string of 3 * 10 9 bytes, hence the name "billion laughs". The resulting
string occupies 3 GB (2.79 GiB) of memory; intermediate strings require
additional memory. Because most parsers don't cache the intermediate
step for every expansion it is repeated over and over again. It
increases the CPU load even more.
An XML document of just a few hundred bytes can disrupt all services on
a machine within seconds.
Example XML:
<!DOCTYPE xmlbomb [
<!ENTITY a "1234567890" >
<!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;">
<!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;">
<!ENTITY d "&c;&c;&c;&c;&c;&c;&c;&c;">
]>
<bomb>&d;</bomb>
quadratic blowup entity expansion
---------------------------------
A quadratic blowup attack is similar to a Billion Laughs attack; it
abuses entity expansion, too. Instead of nested entities it repeats one
large entity with a couple of ten thousand chars over and over again.
The attack isn't as efficient as the exponential case but it avoids
triggering countermeasures of parsers against heavily nested entities.
Some parsers limit the depth and breadth of a single entity but not the
total amount of expanded text throughout an entire XML document.
A medium-sized XML document with a couple of hundred kilobytes can
require a couple of hundred MB to several GB of memory. When the attack
is combined with some level of nested expansion an attacker is able to
achieve a higher ratio of success.
<!DOCTYPE bomb [
<!ENTITY a "xxxxxxx... a couple of ten thousand chars">
]>
<bomb>&a;&a;&a;... repeat</bomb>
external entity expansion (remote)
----------------------------------
Entity declarations can contain more than just text for replacement.
They can also point to external resources by public identifiers or
system identifiers. System identifiers are standard URIs. When the URI
is a URL (e.g. a http:// locator) some parsers download the resource
from the remote location and embed them into the XML document verbatim.
Simple example of a parsed external entity:
<!DOCTYPE external [
<!ENTITY ee SYSTEM "http://www.python.org/some.xml">
]>
<root>ⅇ</root>
The case of parsed external entities works only for valid XML content.
The XML standard also supports unparsed external entities with a NData
declaration.
External entity expansion opens the door to plenty of exploits. An
attacker can abuse a vulnerable XML library and application to rebound
and forward network requests with the IP address of the server. It
highly depends on the parser and the application what kind of exploit is
possible. For example:
* An attacker can circumvent firewalls and gain access to restricted
resources as all the requests are made from an internal and trustworthy
IP address, not from the outside.
* An attacker can abuse a service to attack, spy on or DoS your servers
but also third party services. The attack is disguised with the IP
address of the server and the attacker is able to utilize the high
bandwidth of a big machine.
* An attacker can exhaust additional resources on the machine, e.g. with
requests to a service that doesn't respond or responds with very large
files.
* An attacker may gain knowledge, when, how often and from which IP
address a XML document is accessed.
An attacker could send mail from inside your network if the URL
handler supports smtp:// URIs.
external entity expansion (local file)
--------------------------------------
External entities with references to local files are a sub-case of
external entity expansion. It's listed as an extra attack because it
deserves extra attention. Some XML libraries such as lxml disable
network access by default but still allow entity expansion with local
file access by default. Local files are either referenced with a file://
URL or by a file path (either relative or absolute).
An attacker may be able to access and download all files that can be
read by the application process. This may include critical configuration
files, too.
<!DOCTYPE external [
<!ENTITY ee SYSTEM "file:///PATH/TO/simple.xml">
]>
<root>ⅇ</root>
DTD retrieval
-------------
This case is similar to external entity expansion, too. Some XML
libraries like Python's xml.dom.pulldown retrieve document type
definitions from remote or local locations. Several attack scenarios
from the external entity case apply to this issue as well.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head/>
<body>text</body>
</html>
[View Less]
19
50
Sounds good to me, thanks for the feedback.. Yes, I guess tackling
known issues is a much better use of time than trying to dig my own up
;)
> If you want to be helpful, leave _parse along and find a real bug to work on
> ;-). There are several urllib bug issues. Or check out the code coverage of
> some test module (see devguide), and see if more tests are needed.
1
0
Hope this question belongs here and not in python-ideas, but I'm
curious about _parse in the Request object. Specifically, why it was
decided to write a custom parse function when the likes or urlparse or
urlsplit do essentially the same thing. Doesn't really seem DRY to
me.. I was going to change this to use one of the aforementioned
functions and submit a patch, but wanted to see if there was any
rational behind this that I wasn't seeing.
Yes, it's a very minor issue. Call me a stickler for …
[View More]things like this :)
--
Demian Brecht
http://demianbrecht.github.com
[View Less]
2
1

Re: [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
by Ezio Melotti Feb. 23, 2013
by Ezio Melotti Feb. 23, 2013
Feb. 23, 2013
Hi,
On Sat, Feb 23, 2013 at 5:33 AM, daniel.holth
<python-checkins(a)python.org> wrote:
> http://hg.python.org/peps/rev/de69fe61f300
> changeset: 4764:de69fe61f300
> user: Daniel Holth <dholth(a)fastmail.fm>
> date: Fri Feb 22 22:33:09 2013 -0500
> summary:
> PEP 426: replace implied 'version starts with' with new ~= operator
>
I haven't seen any discussion about this, but FWIW CSS [0] and JQuery
[1] use ^= for this purpose.
^ also indicates …
[View More]the beginning of the string in regular expressions
(this is why ^= was chosen for CSS/JQuery).
They also use ~= to indicate "attribute contains word" [0][2].
Perl also has a similar-looking operator [3] (=~) used to test a regex match.
Best Regards,
Ezio Melotti
[0]: http://www.w3.org/TR/selectors/#selectors
[1]: http://api.jquery.com/attribute-starts-with-selector/
[2]: http://api.jquery.com/attribute-contains-word-selector/
[3]: http://perldoc.perl.org/perlop.html#Binding-Operators
[View Less]
3
3
In doing the detailed review of PEP 426 as BDFL-Delegate, I keep
noticing confusing problems with the current spec that mean I want to
become a *co-author* on the spec, rather than explaining to the
current authors the aspects I object to, until they produce a version
that I'm happy with (this is frustrating for the authors as well,
since several of the problems have been inherited from the previous
version of the spec rather than being new in the current version).
Now, Guido's authored and …
[View More]accepted his own PEPs in the past, but to
date we've avoided letting anyone else do that. Since I *definitely*
want to co-author the new metadata PEP (mostly to address issues with
the version specifier section and to include the *rationale* for
changes, rather than merely listing them as previous versions of the
metadata PEPs have done), that means one of the following needs to
happen:
- someone else volunteers to be BDFL-Delegate for PEP 426 (MvL, perhaps?)
- I get clear approval (perhaps from Guido?) to be both co-author
*and* BDFL-Delegate for PEP 426
Regards,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
[View Less]
19
46
ACTIVITY SUMMARY (2013-02-15 - 2013-02-22)
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:
open 3866 (+21)
closed 25186 (+45)
total 29052 (+66)
Open issues with patches: 1667
Issues opened (46)
==================
#17212: os.path.isfile() in Python 3.3 sometimes fails
http://bugs.python.org/issue17212 opened by gpoore
#17213: ctypes loads wrong version …
[View More]of C runtime, leading to error mess
http://bugs.python.org/issue17213 opened by dancol
#17214: http.client.HTTPConnection.putrequest encode error
http://bugs.python.org/issue17214 opened by Mi.Zou
#17216: sparc linux build fails with "could not import runpy module"
http://bugs.python.org/issue17216 opened by uservorname.usernachname
#17217: Fix test discovery for test_format.py on Windows
http://bugs.python.org/issue17217 opened by zach.ware
#17218: support title and description in argparse add_mutually_exclusi
http://bugs.python.org/issue17218 opened by chris.jerdonek
#17219: cross add Python's library directory when building python stan
http://bugs.python.org/issue17219 opened by rpetrov
#17220: Little enhancements of _bootstrap.py
http://bugs.python.org/issue17220 opened by serhiy.storchaka
#17221: Resort Misc/NEWS
http://bugs.python.org/issue17221 opened by serhiy.storchaka
#17222: py_compile.compile() explicitly sets st_mode for written files
http://bugs.python.org/issue17222 opened by Arfrever
#17223: Initializing array.array with unicode type code and buffer seg
http://bugs.python.org/issue17223 opened by mjacob
#17224: can not open idle in python 2.7.3
http://bugs.python.org/issue17224 opened by hayeswu
#17226: libintl should also check for libiconv
http://bugs.python.org/issue17226 opened by alanh
#17227: devguide: buggy heading numbers
http://bugs.python.org/issue17227 opened by pitrou
#17229: unable to discover preferred HTTPConnection class
http://bugs.python.org/issue17229 opened by samwyse
#17231: Mark __del__ not being called in cycles as an impl detail
http://bugs.python.org/issue17231 opened by fijall
#17232: Improve -O docs
http://bugs.python.org/issue17232 opened by fijall
#17233: http.client header debug output format
http://bugs.python.org/issue17233 opened by Kim.Gräsman
#17234: python-2.7.3-r3: crash in visit_decref()
http://bugs.python.org/issue17234 opened by mmokrejs
#17237: m68k aligns on 16bit boundaries.
http://bugs.python.org/issue17237 opened by alanh
#17238: Enhance import statement completion
http://bugs.python.org/issue17238 opened by Ramchandra Apte
#17239: XML vulnerabilities in Python
http://bugs.python.org/issue17239 opened by christian.heimes
#17240: argparse: subcommand name and arity
http://bugs.python.org/issue17240 opened by Thibault.Kruse
#17243: The changes made for issue 4074 should be documented
http://bugs.python.org/issue17243 opened by r.david.murray
#17244: py_compile.compile() fails to raise exceptions when writing of
http://bugs.python.org/issue17244 opened by Arfrever
#17245: ctypes libffi needs to align the x86 stack to 16 bytes
http://bugs.python.org/issue17245 opened by gregory.p.smith
#17246: cgitb fails when frame arguments are deleted (due to inspect b
http://bugs.python.org/issue17246 opened by Andrew.Lutomirski
#17247: int and float should detect inconsistent format strings
http://bugs.python.org/issue17247 opened by christian.heimes
#17249: reap threads in test_capi
http://bugs.python.org/issue17249 opened by ezio.melotti
#17250: argparse: Issue 15906 patch; positional with nargs='*' and str
http://bugs.python.org/issue17250 opened by paul.j3
#17251: LWPCookieJar load() set domain_specifed wrong
http://bugs.python.org/issue17251 opened by B. Kyven
#17254: add thai encoding aliases to encodings.aliases
http://bugs.python.org/issue17254 opened by fomcl(a)yahoo.com
#17258: multiprocessing.connection challenge implicitly uses MD5
http://bugs.python.org/issue17258 opened by dmalcolm
#17259: locale.format() rounding is not reliable for floats
http://bugs.python.org/issue17259 opened by Francis.Nimick
#17261: multiprocessing.manager BaseManager cannot return proxies from
http://bugs.python.org/issue17261 opened by Wilson.Harron
#17263: crash when tp_dealloc allows other threads
http://bugs.python.org/issue17263 opened by Albert.Zeyer
#17264: Update Building C and C++ Extensions with distutils documentat
http://bugs.python.org/issue17264 opened by berker.peksag
#17267: datetime.time support for '+' and 'now'
http://bugs.python.org/issue17267 opened by ronaldoussoren
#17268: Context managers written as C types no longer work in Python 2
http://bugs.python.org/issue17268 opened by lemburg
#17269: getaddrinfo segfaults on OS X when provided with invalid argum
http://bugs.python.org/issue17269 opened by tibbe
#17272: request.full_url: unexpected results on assignment
http://bugs.python.org/issue17272 opened by dbrecht
#17273: multiprocessing.pool.Pool task/worker handlers are not fork sa
http://bugs.python.org/issue17273 opened by abn
#17274: distutils silently omits relative symlinks
http://bugs.python.org/issue17274 opened by fberger
#17275: io.BufferedWriter shows wrong type in argument error message
http://bugs.python.org/issue17275 opened by mjacob
#17276: HMAC: deprecate default hash
http://bugs.python.org/issue17276 opened by christian.heimes
#17277: incorrect line numbers in backtrace after removing a trace fun
http://bugs.python.org/issue17277 opened by xdegaye
Most recent 15 issues with no replies (15)
==========================================
#17277: incorrect line numbers in backtrace after removing a trace fun
http://bugs.python.org/issue17277
#17274: distutils silently omits relative symlinks
http://bugs.python.org/issue17274
#17261: multiprocessing.manager BaseManager cannot return proxies from
http://bugs.python.org/issue17261
#17251: LWPCookieJar load() set domain_specifed wrong
http://bugs.python.org/issue17251
#17250: argparse: Issue 15906 patch; positional with nargs='*' and str
http://bugs.python.org/issue17250
#17246: cgitb fails when frame arguments are deleted (due to inspect b
http://bugs.python.org/issue17246
#17245: ctypes libffi needs to align the x86 stack to 16 bytes
http://bugs.python.org/issue17245
#17243: The changes made for issue 4074 should be documented
http://bugs.python.org/issue17243
#17239: XML vulnerabilities in Python
http://bugs.python.org/issue17239
#17238: Enhance import statement completion
http://bugs.python.org/issue17238
#17233: http.client header debug output format
http://bugs.python.org/issue17233
#17229: unable to discover preferred HTTPConnection class
http://bugs.python.org/issue17229
#17224: can not open idle in python 2.7.3
http://bugs.python.org/issue17224
#17219: cross add Python's library directory when building python stan
http://bugs.python.org/issue17219
#17218: support title and description in argparse add_mutually_exclusi
http://bugs.python.org/issue17218
Most recent 15 issues waiting for review (15)
=============================================
#17275: io.BufferedWriter shows wrong type in argument error message
http://bugs.python.org/issue17275
#17272: request.full_url: unexpected results on assignment
http://bugs.python.org/issue17272
#17269: getaddrinfo segfaults on OS X when provided with invalid argum
http://bugs.python.org/issue17269
#17264: Update Building C and C++ Extensions with distutils documentat
http://bugs.python.org/issue17264
#17258: multiprocessing.connection challenge implicitly uses MD5
http://bugs.python.org/issue17258
#17249: reap threads in test_capi
http://bugs.python.org/issue17249
#17245: ctypes libffi needs to align the x86 stack to 16 bytes
http://bugs.python.org/issue17245
#17239: XML vulnerabilities in Python
http://bugs.python.org/issue17239
#17227: devguide: buggy heading numbers
http://bugs.python.org/issue17227
#17223: Initializing array.array with unicode type code and buffer seg
http://bugs.python.org/issue17223
#17221: Resort Misc/NEWS
http://bugs.python.org/issue17221
#17220: Little enhancements of _bootstrap.py
http://bugs.python.org/issue17220
#17219: cross add Python's library directory when building python stan
http://bugs.python.org/issue17219
#17217: Fix test discovery for test_format.py on Windows
http://bugs.python.org/issue17217
#17211: pkgutil.iter_modules and walk_packages should return a namedtu
http://bugs.python.org/issue17211
Top 10 most discussed issues (10)
=================================
#17237: m68k aligns on 16bit boundaries.
http://bugs.python.org/issue17237 25 msgs
#15767: add ImportNotFoundError
http://bugs.python.org/issue15767 18 msgs
#14468: Update cloning guidelines in devguide
http://bugs.python.org/issue14468 11 msgs
#17222: py_compile.compile() explicitly sets st_mode for written files
http://bugs.python.org/issue17222 11 msgs
#17221: Resort Misc/NEWS
http://bugs.python.org/issue17221 9 msgs
#17227: devguide: buggy heading numbers
http://bugs.python.org/issue17227 7 msgs
#14905: zipimport.c needs to support namespace packages when no 'direc
http://bugs.python.org/issue14905 5 msgs
#15004: add weakref support to types.SimpleNamespace
http://bugs.python.org/issue15004 5 msgs
#16612: Integrate "Argument Clinic" specialized preprocessor into CPyt
http://bugs.python.org/issue16612 5 msgs
#17177: Document/deprecate imp
http://bugs.python.org/issue17177 5 msgs
Issues closed (43)
==================
#6138: './configure; make install' fails in setup.py step if .pydistu
http://bugs.python.org/issue6138 closed by ned.deily
#6541: SpooledTemporaryFile breakages
http://bugs.python.org/issue6541 closed by r.david.murray
#7469: Design and History FAQ entry on Floating Point does not mentio
http://bugs.python.org/issue7469 closed by r.david.murray
#7842: py_compile.compile SyntaxError output
http://bugs.python.org/issue7842 closed by r.david.murray
#7963: Misleading error message from object(arg)
http://bugs.python.org/issue7963 closed by r.david.murray
#7981: False failure with doctest NORMALIZE_WHITESPACE in 3.1.1
http://bugs.python.org/issue7981 closed by r.david.murray
#8745: zipimport is a bit slow
http://bugs.python.org/issue8745 closed by serhiy.storchaka
#8930: messed up formatting after reindenting
http://bugs.python.org/issue8930 closed by r.david.murray
#9669: regexp: zero-width matches in MIN_UNTIL
http://bugs.python.org/issue9669 closed by serhiy.storchaka
#13153: IDLE crashes when pasting non-BMP unicode char on Py3
http://bugs.python.org/issue13153 closed by serhiy.storchaka
#13169: Regular expressions with 0 to 65536 repetitions raises Overflo
http://bugs.python.org/issue13169 closed by serhiy.storchaka
#13700: imaplib.IMAP4.authenticate authobject does not work correctly
http://bugs.python.org/issue13700 closed by r.david.murray
#15003: make PyNamespace_New() public
http://bugs.python.org/issue15003 closed by eric.snow
#15022: types.SimpleNamespace needs to be picklable
http://bugs.python.org/issue15022 closed by eric.snow
#17035: Use new style classes in {class, static}method examples
http://bugs.python.org/issue17035 closed by ezio.melotti
#17143: trace.py uses _warn without importing it
http://bugs.python.org/issue17143 closed by ezio.melotti
#17163: Fix test discovery for test_file.py
http://bugs.python.org/issue17163 closed by ezio.melotti
#17175: update PEP 430
http://bugs.python.org/issue17175 closed by ezio.melotti
#17178: Clarify empty iterable result in any/all.__doc__, as in manual
http://bugs.python.org/issue17178 closed by ezio.melotti
#17184: re.VERBOSE doesn't respect whitespace in '( ?P<foo>...)'
http://bugs.python.org/issue17184 closed by ezio.melotti
#17193: Use binary prefixes
http://bugs.python.org/issue17193 closed by serhiy.storchaka
#17203: add long option names to unittest discovery docs
http://bugs.python.org/issue17203 closed by chris.jerdonek
#17208: add note/warning about daemon threads
http://bugs.python.org/issue17208 closed by pitrou
#17215: documentation misprints
http://bugs.python.org/issue17215 closed by asvetlov
#17225: JSON decoder reports wrong column number on first line
http://bugs.python.org/issue17225 closed by serhiy.storchaka
#17228: Building without PYMALLOC fails
http://bugs.python.org/issue17228 closed by python-dev
#17230: when forking, buffered output is not flushed first.
http://bugs.python.org/issue17230 closed by gregory.p.smith
#17235: "make sharedinstall" ignores ./configure settings
http://bugs.python.org/issue17235 closed by ned.deily
#17236: format_spec for sequence joining
http://bugs.python.org/issue17236 closed by r.david.murray
#17241: Python-2.3.5.exe file possibly corrupt
http://bugs.python.org/issue17241 closed by skrah
#17242: Fix code highlight in devguide/docquality.rst
http://bugs.python.org/issue17242 closed by ezio.melotti
#17248: test_posix chown -1, 0 tests fail if user has group root
http://bugs.python.org/issue17248 closed by serhiy.storchaka
#17252: Latin Capital Letter I with Dot Above
http://bugs.python.org/issue17252 closed by pitrou
#17253: stdin.readline behaviour different between IDLE and the consol
http://bugs.python.org/issue17253 closed by serhiy.storchaka
#17255: test_any and test_all should validate short-circuiting behavio
http://bugs.python.org/issue17255 closed by ezio.melotti
#17256: code example in C API docsshould be highlighted
http://bugs.python.org/issue17256 closed by ezio.melotti
#17257: re module shows unexpected non-greedy behavior when using grou
http://bugs.python.org/issue17257 closed by Hendrik.Lemelson
#17260: Seg fault when calling unicode() on old style object in virtua
http://bugs.python.org/issue17260 closed by ned.deily
#17262: OrderedDict not ordering properly when int and float keys are
http://bugs.python.org/issue17262 closed by benjamin.peterson
#17265: Fix code highlight in the string.Template example
http://bugs.python.org/issue17265 closed by ezio.melotti
#17266: Idle + tcl 8.6.0 Can't convert '_tkinter.Tcl_Obj' object to st
http://bugs.python.org/issue17266 closed by serhiy.storchaka
#17270: make the section header doc convention more clearly optional
http://bugs.python.org/issue17270 closed by chris.jerdonek
#17271: NamedTemporaryFile expects bytes, not string in documentation
http://bugs.python.org/issue17271 closed by ezio.melotti
[View Less]
1
0
Since the PyPI security notice of 2013-02-15 I've been unable to upload
to PyPI via "setup.py upload".
I changed my password during the grace period, and have reset it, but
it's still rejected:
Upload failed (401): Incorrect password
I can login to PyPI with the password.
Can anyone suggest what could be wrong?
2
4

xml.sax and xml.dom fetch DTDs by default (was XML DoS vulnerabilities and exploits in Python)
by Paul Boddie Feb. 21, 2013
by Paul Boddie Feb. 21, 2013
Feb. 21, 2013
Perhaps related to the discussion of denial-of-service vulnerabilities is the
matter of controlling access to remote resources. I suppose that after the
following bug was closed, no improvements were made to the standard library:
http://bugs.python.org/issue2124
Do Python programs still visit the W3C site millions of times every day to
download DTDs that they are not, by default, able to remember from their last
visit?
Paul
2
1

Feb. 20, 2013
FYI
---------- Forwarded message ----------
From: Nick Coghlan <ncoghlan(a)gmail.com>
Date: Sun, Feb 17, 2013 at 8:10 PM
Subject: PEP 426 is now the draft spec for distribution metadata 2.0
To: "DistUtils mailing list\"\"" <distutils-sig(a)python.org>
The latest draft of PEP 426 is up at http://www.python.org/dev/peps/pep-0426/
Major changes since the last draft:
1. Metadata-Version is 2.0 rather than 1.3, and the field now has the
same major.minor semantics as are defined for …
[View More]wheel versions in PEP
427 (i.e. if a tool sees a major version number it doesn't recognise,
it should give up rather than trying to guess what to do with it,
while it's OK to process a higher minor version)
2. The "Private-Version" field is added, and several examples are
given showing how to use it in conjunction with translated public
versions when a project wants to use a version numbering scheme that
the standard installation tools won't understand.
3. The environment markers section more clearly covers the need to
handle parentheses (this was mentioned in the text, but not the
pseudo-grammar), and the fields which support those markers have an
explicit cross-reference to that section of the spec.
4. Leading/trailing whitespace and date based versioning are
explicitly excluded from valid public versions
5. Version compatibility statistics are provided for this PEP relative
to PEP 386 (the analysis script has been added to the PEP repo if
anyone wants to check my numbers)
6. I have reclaimed BDFL-Delegate status (with Guido's approval)
Since getting wheel support into pip no longer depends on this version
of the metadata spec, I plan to leave it open for comment for another
week, and then accept it next weekend if I don't hear any significant
objections.
Regards,
Nick.
==========================
PEP: 426
Title: Metadata for Python Software Packages 2.0
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth <dholth(a)fastmail.fm>,
Donald Stufft <donald(a)stufft.io>,
Nick Coghlan <ncoghlan(a)gmail.com>
BDFL-Delegate: Nick Coghlan <ncoghlan(a)gmail.com>
Discussions-To: Distutils SIG
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30 Aug 2012
Post-History: 14 Nov 2012, 5 Feb 2013, 7 Feb 2013, 9 Feb 2013
Abstract
========
This PEP describes a mechanism for adding metadata to Python distributions.
It includes specifics of the field names, and their semantics and
usage.
This document specifies version 2.0 of the metadata format.
Version 1.0 is specified in PEP 241.
Version 1.1 is specified in PEP 314.
Version 1.2 is specified in PEP 345.
Version 2.0 of the metadata format adds fields designed to make
third-party packaging of Python Software easier and defines a formal
extension mechanism. It also adds support for optional features of
distributions and allows the description to be placed into a payload
section. Finally, this version addresses several issues with the
previous iteration of the standard version identification scheme.
Metadata files
==============
The syntax defined in this PEP is for use with Python distribution
metadata files. The file format is a simple UTF-8 encoded Key: value
format with case-insensitive keys and no maximum line length, optionally
followed by a blank line and a payload containing a description of the
distribution.
This format is parseable by the ``email`` module with an appropriate
``email.policy.Policy()``. When ``metadata`` is a Unicode string,
```email.parser.Parser().parsestr(metadata)`` is a serviceable parser.
There are three standard locations for these metadata files:
* the ``PKG-INFO`` file included in the base directory of Python
source distribution archives (as created by the distutils ``sdist``
command)
* the ``{distribution}-{version}.dist-info/METADATA`` file in a ``wheel``
binary distribution archive (as described in PEP 425, or a later version
of that specification)
* the ``{distribution}-{version}.dist-info/METADATA`` files in a local
Python installation database (as described in PEP 376, or a later version
of that specification)
Other tools involved in Python distribution may also use this format.
Encoding
========
Metadata 2.0 files are UTF-8 with the restriction that keys must be
ASCII. Parser implementations should be aware that older versions of
the Metadata specification do not specify an encoding.
Metadata header fields
=======================
This section specifies the names and semantics of each of the
supported fields in the metadata header.
In a single Metadata 2.0 file, fields marked with "(optional)" may occur
0 or 1 times. Fields marked with "(multiple use)" may be specified
0, 1 or more times. Only "Metadata-Version", "Name", "Version", and
"Summary" must appear exactly once.
The fields may appear in any order within the header section of the file.
Metadata-Version
----------------
Version of the file format; "2.0" is the only legal value.
Automated tools should warn if ``Metadata-Version`` is greater than the
highest version they support, and must fail if ``Metadata-Version`` has
a greater major version than the highest version they support.
Example::
Metadata-Version: 2.0
Name
----
The name of the distribution.
Example::
Name: BeagleVote
Version
-------
The distribution's public version identifier. Public versions are designed
for consumption by automated tools and are strictly ordered according
to a defined scheme. See `Version scheme`_ below.
Example::
Version: 1.0a2
Summary
-------
A one-line summary of what the distribution does.
Example::
Summary: A module for collecting votes from beagles.
Private-Version (optional)
--------------------------
An arbitrary private version label. Private version labels are intended
for internal use by a project, and cannot be used in version specifiers.
See `Compatibility with other version schemes`_ below.
Examples::
Private-Version: 1.0.0-alpha.1
Private-Version: 1.3.7+build.11.e0f985a
Private-Version: v1.8.1.301.ga0df26f
Private-Version: 2013.02.17.dev123
Description (optional, deprecated)
----------------------------------
Starting with Metadata 2.0, the recommended place for the description is in
the payload section of the document, after the last header. The description
does not need to be reformatted when it is included in the payload.
See `Describing the Distribution`_ for more information on the expected
contents of this field.
Since a line separator immediately followed by another line separator
indicates the end of the headers section, any line separators in a
``Description`` header field must be suffixed by whitespace to
indicate continuation.
It is an error to provide both a ``Description`` header and a metadata
payload.
Keywords (optional)
-------------------
A list of additional whitespace separated keywords to be used to assist
searching for the distribution in a larger catalog.
Example::
Keywords: dog puppy voting election
Home-page (optional)
--------------------
A string containing the URL for the distribution's home page.
Example::
Home-page: http://www.example.com/~cschultz/bvote/
Download-URL (optional)
-----------------------
A string containing the URL from which this version of the distribution
can be downloaded. (This means that the URL can't be something like
".../BeagleVote-latest.tgz", but instead must be ".../BeagleVote-0.45.tgz".)
Project-URL (multiple use)
--------------------------
A string containing a label and a browsable URL for the project, separated
by the last occurrence of comma and space ", ".
The label consists of any permitted header text, including commas.
Example::
Bug, Issue Tracker, http://bitbucket.org/tarek/distribute/issues/
Author (optional)
-----------------
A string containing the author's name at a minimum; additional
contact information may be provided.
Example::
Author: C. Schultz, Universal Features Syndicate,
Los Angeles, CA <cschultz(a)peanuts.example.com>
Author-email (optional)
-----------------------
A string containing the author's e-mail address. It contains a name
and e-mail address in the RFC 5322 recommended ``Address Specification``
format.
Example::
Author-email: "C. Schultz" <cschultz(a)example.com>
Maintainer (optional)
---------------------
A string containing the maintainer's name at a minimum; additional
contact information may be provided.
Note that this field is intended for use when a project is being
maintained by someone other than the original author: it should be
omitted if it is identical to ``Author``.
Example::
Maintainer: C. Schultz, Universal Features Syndicate,
Los Angeles, CA <cschultz(a)peanuts.example.com>
Maintainer-email (optional)
---------------------------
A string containing the maintainer's e-mail address. It has the same
format as ``Author-email``.
Note that this field is intended for use when a project is being
maintained by someone other than the original author: it should be
omitted if it is identical to ``Author-email``.
Example::
Maintainer-email: "C. Schultz" <cschultz(a)example.com>
License (optional)
------------------
Text indicating the license covering the distribution where the license
is not a selection from the "License" Trove classifiers. See
"Classifier" below. This field may also be used to specify a
particular version of a license which is named via the ``Classifier``
field, or to indicate a variation or exception to such a license.
Examples::
License: This software may only be obtained by sending the
author a postcard, and then the user promises not
to redistribute it.
License: GPL version 3, excluding DRM provisions
The full text of the license would normally be included in a separate
file.
Classifier (multiple use)
-------------------------
Each entry is a string giving a single classification value
for the distribution. Classifiers are described in PEP 301 [2].
`Environment markers`_ may be used with this field.
Examples::
Classifier: Development Status :: 4 - Beta
Classifier: Environment :: Console (Text Based)
Provides-Dist (multiple use)
----------------------------
Each entry contains a string naming a requirement that is satisfied by
installing this distribution. These strings must be of the form
``Name`` or ``Name (Version)``, following the formats of the corresponding
field definitions.
A distribution may provide additional names, e.g. to indicate that
multiple projects have been merged into and replaced by a single
distribution or to indicate that this project is a substitute for another.
For instance, distribute (a fork of setuptools) can include a
``Provides-Dist: setuptools`` entry to prevent the conflicting
package from being downloaded and installed when distribute is already
installed. A distribution that has been merged with another might
``Provides-Dist`` the obsolete name(s) to satisfy any projects that
require the obsolete distribution's name.
A distribution may also provide a "virtual" project name, which does
not correspond to any separately-distributed project: such a name
might be used to indicate an abstract capability which could be supplied
by one of multiple projects. E.g., multiple projects might supply
RDBMS bindings for use by a given ORM: each project might declare
that it provides ``ExampleORM-somedb-bindings``, allowing other
projects to depend only on having at least one of them installed.
A version declaration may be supplied and must follow the rules described
in `Version scheme`_. The distribution's version identifier will be implied
if none is specified.
`Environment markers`_ may be used with this field.
Examples::
Provides-Dist: ThisProject
Provides-Dist: AnotherProject (3.4)
Provides-Dist: virtual_package
Provides-Extra (multiple use)
-----------------------------
A string containing the name of an optional feature. Must be printable
ASCII, not containing whitespace, comma (,), or square brackets [].
May be used to make a dependency conditional on whether the optional
feature has been requested.
See `Optional Features`_ for details on the use of this field.
Example::
Name: beaglevote
Provides-Extra: pdf
Requires-Dist: reportlab; extra == 'pdf'
Requires-Dist: nose; extra == 'test'
Requires-Dist: sphinx; extra == 'doc'
Obsoleted-By (optional)
-----------------------
Indicates that this project is no longer being developed. The named
project provides a substitute or replacement.
A version declaration may be supplied and must follow the rules described
in `Version specifiers`_.
Possible uses for this field include handling project name changes and
project mergers.
Examples::
Name: BadName
Obsoleted-By: AcceptableName
Name: SeparateProject
Obsoleted-By: MergedProject (>=4.0.0)
Requires-Dist (multiple use)
----------------------------
Each entry contains a string naming some other distutils
project required by this distribution.
The format of a requirement string is identical to that of a distribution
name (e.g., as found in the ``Name:`` field) optionally followed by a
version declaration within parentheses.
The distribution names should correspond to names as found on the `Python
Package Index`_; often the same as, but distinct from, the module names
as accessed with ``import x``.
`Environment markers`_ may be used with this field.
Version declarations must follow the rules described in
`Version specifiers`_
Distributions may also depend on optional features of other distributions.
See `Optional Features`_ for details.
Examples::
Requires-Dist: pkginfo
Requires-Dist: PasteDeploy
Requires-Dist: zope.interface (>3.5.0)
Dependencies mentioned in ``Requires-Dist`` may be installed exclusively
at run time and are not guaranteed to be available when creating or
installing a package. If a dependency is needed during distribution
creation or installation *and* at run time, it should be listed under
both ``Requires-Dist`` and ``Setup-Requires-Dist``.
Setup-Requires-Dist (multiple use)
----------------------------------
Like ``Requires-Dist``, but names dependencies needed in order to build,
package or install the distribution -- in distutils, a dependency imported
by ``setup.py`` itself. Commonly used to bring in extra compiler support
or a package needed to generate a manifest from version control.
Examples::
Setup-Requires-Dist: custom_setup_command
Dependencies mentioned in ``Setup-Requires-Dist`` may be installed
exclusively for setup and are not guaranteed to be available at run time.
If a dependency is needed during distribution creation or installation
*and* at run time, it should be listed under both ``Requires-Dist`` and
``Setup-Requires-Dist``.
Requires-Python (multiple use)
------------------------------
This field specifies the Python version(s) that the distribution is
guaranteed to be compatible with.
`Environment markers`_ may be used with this field.
Version declarations must be in the format specified in
`Version specifiers`_.
Examples::
Requires-Python: 3.2
Requires-Python: >3.1
Requires-Python: >=2.3.4
Requires-Python: >=2.5,<2.7
If specified multiple times, the Python version must satisfy all such
constraints to be considered compatible. This is most useful in combination
with appropriate `Environment markers`_.
For example, if a feature was initially introduced to Python as a
Unix-specific addition, and then Windows support was added in the
subsequent release, this could be indicated with the following pair
of entries::
Requires-Python: >= 3.1
Requires-Python: >= 3.2; sys.platform == 'win32'
Requires-External (multiple use)
--------------------------------
Each entry contains a string describing some dependency in the
system that the distribution is to be used. This field is intended to
serve as a hint to downstream project maintainers, and has no
semantics which are meaningful to the ``distutils`` distribution.
The format of a requirement string is a name of an external
dependency, optionally followed by a version declaration within
parentheses.
`Environment markers`_ may be used with this field.
Because they refer to non-Python software releases, version identifiers
for this field are **not** required to conform to the format
described in `Version scheme`_: they should correspond to the
version scheme used by the external dependency.
Notice that there is no particular rule on the strings to be used.
Examples::
Requires-External: C
Requires-External: libpng (>=1.5)
Platform (multiple use)
-----------------------
A Platform specification describing an operating system supported by
the distribution which is not listed in the "Operating System" Trove
classifiers. See `Classifier`__ above.
__ `Classifier (multiple use)`_
Examples::
Platform: ObscureUnix
Platform: RareDOS
Supported-Platform (multiple use)
---------------------------------
Binary distributions containing a metadata file will use the
Supported-Platform field in their metadata to specify the OS and
CPU for which the binary distribution was compiled. The semantics of
the Supported-Platform field are not specified in this PEP.
Example::
Supported-Platform: RedHat 7.2
Supported-Platform: i386-win32-2791
Extension (multiple use)
------------------------
An ASCII string, not containing whitespace or the ``/`` character, that
indicates the presence of extended metadata. The additional fields
defined by the extension are then prefixed with the name of the extension
and the ``/`` character.
For example::
Extension: Chili
Chili/Type: Poblano
Chili/Heat: Mild
To avoid name conflicts, it is recommended that distribution names be used
to identify metadata extensions. This practice will also make it easier to
find authoritative documentation for metadata extensions.
As the order of the metadata headers is not constrained, the
``Extension: Chili`` field may appear before or after the corresponding
extension fields ``Chili/Type:`` etc.
Values in extension fields must still respect the general formatting
requirements for metadata headers.
A bare ``Extension: Name`` entry with no corresponding extension fields is
permitted. It may, for example, indicate the expected presence of an
additional metadata file rather than the presence of extension fields.
An extension field with no corresponding ``Extension: Name`` entry is an
error.
Describing the distribution
===========================
The distribution metadata should include a longer description of the
distribution that may run to several paragraphs. Software that deals
with metadata should not assume any maximum size for the description.
The recommended location for the description is in the metadata payload,
separated from the header fields by at least one completely blank line
(that is, two successive line separators with no other characters
between them, not even whitespace).
Alternatively, the description may be provided in the `Description`__
metadata header field. Providing both a ``Description`` field and a
payload is an error.
__ `Description (optional, deprecated)`_
The distribution description can be written using reStructuredText
markup [1]_. For programs that work with the metadata, supporting
markup is optional; programs may also display the contents of the
field as plain text without any special formatting. This means that
authors should be conservative in the markup they use.
Version scheme
==============
Public version identifiers must comply with the following scheme::
N[.N]+[{a|b|c|rc}N][.postN][.devN]
Version identifiers which do not comply with this scheme are an error.
Version identifiers must not include leading or trailing whitespace.
Any given version will be a "release", "pre-release", "post-release" or
"developmental release" as defined in the following sections.
.. note::
Some hard to read version identifiers are permitted by this scheme
in order to better accommodate the wide range of versioning practices
across existing public and private Python projects.
Accordingly, some of the versioning practices which are technically
permitted by the PEP are strongly discouraged for new projects. Where
this is the case, the relevant details are noted in the following
sections.
Releases
--------
A release number is a version identifier that consists solely of one or
more non-negative integer values, separated by dots::
N[.N]+
Releases within a project must be numbered in a consistently increasing
fashion. Ordering considers the numeric value of each component
in turn, with "component does not exist" sorted ahead of all numeric
values.
Date based release numbers are explicitly excluded from compatibility with
this scheme, as they hinder automatic translation to other versioning
schemes, as well as preventing the adoption of semantic versioning without
changing the name of the project. Accordingly, a leading release component
greater than or equal to ``1980`` is an error.
While any number of additional components after the first are permitted
under this scheme, the most common variants are to use two components
("major.minor") or three components ("major.minor.micro").
For example::
0.9
0.9.1
0.9.2
...
0.9.10
0.9.11
1.0
1.0.1
1.1
2.0
2.0.1
A release series is any set of release numbers that start with a common
prefix. For example, ``3.3.1``, ``3.3.5`` and ``3.3.9.45`` are all
part of the ``3.3`` release series.
.. note::
Using both ``X.Y`` and ``X.Y.0`` as distinct release numbers within the
scope of a single release series is strongly discouraged, as it makes the
version ordering ambiguous for human readers. Automated tools should
either treat this case as an error, or else interpret an ``X.Y.0``
release as coming *after* the corresponding ``X.Y`` release.
The recommended practice is to always use release numbers of a consistent
length (that is, always include the trailing ``.0``). An acceptable
alternative is to consistently omit the trailing ``.0``. The example
above shows both styles, always including the ``.0`` at the second
level and consistently omitting it at the third level.
Pre-releases
------------
Some projects use an "alpha, beta, release candidate" pre-release cycle to
support testing by their users prior to a full release.
If used as part of a project's development cycle, these pre-releases are
indicated by a suffix appended directly to the last component of the
release number::
X.YaN # Alpha release
X.YbN # Beta release
X.YcN # Release candidate (alternative notation: X.YrcN)
X.Y # Full release
The pre-release suffix consists of an alphabetical identifier for the
pre-release phase, along with a non-negative integer value. Pre-releases for
a given release are ordered first by phase (alpha, beta, release candidate)
and then by the numerical component within that phase.
.. note::
Using both ``c`` and ``rc`` to identify release candidates within
the scope of a single release is strongly discouraged, as it makes the
version ordering ambiguous for human readers. Automated tools should
either treat this case as an error, or else interpret all ``rc`` versions
as coming after all ``c`` versions (that is, ``rc1`` indicates a later
version than ``c2``).
Post-releases
-------------
Some projects use post-releases to address minor errors in a release that
do not affect the distributed software (for example, correcting an error
in the release notes).
If used as part of a project's development cycle, these post-releases are
indicated by a suffix appended directly to the last component of the
release number::
X.Y.postN # Post-release
The post-release suffix consists of the string ``.post``, followed by a
non-negative integer value. Post-releases are ordered by their
numerical component, immediately following the corresponding release,
and ahead of any subsequent release.
.. note::
The use of post-releases to publish maintenance releases containing
actual bug fixes is strongly discouraged. In general, it is better
to use a longer release number and increment the final component
for each maintenance release.
Post-releases are also permitted for pre-releases::
X.YaN.postM # Post-release of an alpha release
X.YbN.postM # Post-release of a beta release
X.YcN.postM # Post-release of a release candidate
.. note::
Creating post-releases of pre-releases is strongly discouraged, as
it makes the version identifier difficult to parse for human readers.
In general, it is substantially clearer to simply create a new
pre-release by incrementing the numeric component.
Developmental releases
----------------------
Some projects make regular developmental releases, and system packagers
(especially for Linux distributions) may wish to create early releases
which do not conflict with later project releases.
If used as part of a project's development cycle, these developmental
releases are indicated by a suffix appended directly to the last
component of the release number::
X.Y.devN # Developmental release
The developmental release suffix consists of the string ``.dev``,
followed by a non-negative integer value. Developmental releases are ordered
by their numerical component, immediately before the corresponding release
(and before any pre-releases), and following any previous release.
Developmental releases are also permitted for pre-releases and
post-releases::
X.YaN.devM # Developmental release of an alpha release
X.YbN.devM # Developmental release of a beta release
X.YcN.devM # Developmental release of a release candidate
X.Y.postN.devM # Developmental release of a post-release
.. note::
Creating developmental releases of pre-releases is strongly
discouraged, as it makes the version identifier difficult to parse for
human readers. In general, it is substantially clearer to simply create
additional pre-releases by incrementing the numeric component.
Developmental releases of post-releases are also strongly discouraged,
but they may be appropriate for projects which use the post-release
notation for full maintenance releases which may include code changes.
Examples of compliant version schemes
-------------------------------------
The standard version scheme is designed to encompass a wide range of
identification practices across public and private Python projects. In
practice, a single project attempting to use the full flexibility offered
by the scheme would create a situation where human users had difficulty
figuring out the relative order of versions, even though the rules above
ensure all compliant tools will order them consistently.
The following examples illustrate a small selection of the different
approaches projects may choose to identify their releases, while still
ensuring that the "latest release" and the "latest stable release" can
be easily determined, both by human users and automated tools.
Simple "major.minor" versioning::
0.1
0.2
0.3
1.0
1.1
...
Simple "major.minor.micro" versioning::
1.1.0
1.1.1
1.1.2
1.2.0
...
"major.minor" versioning with alpha, beta and release candidate
pre-releases::
0.9
1.0a1
1.0a2
1.0b1
1.0c1
1.0
1.1a1
...
"major.minor" versioning with developmental releases, release candidates
and post-releases for minor corrections::
0.9
1.0.dev1
1.0.dev2
1.0.dev3
1.0.dev4
1.0rc1
1.0rc2
1.0
1.0.post1
1.1.dev1
...
Summary of permitted suffixes and relative ordering
---------------------------------------------------
.. note::
This section is intended primarily for authors of tools that
automatically process distribution metadata, rather than authors
of Python distributions deciding on a versioning scheme.
The numeric release component of version identifiers should be sorted in
the same order as Python's tuple sorting when the release number is
parsed as follows::
tuple(map(int, release_number.split(".")))
Within a numeric release (``1.0``, ``2.7.3``), the following suffixes
are permitted and are ordered as shown::
.devN, aN, bN, cN, rcN, <no suffix>, .postN
Note that `rc` will always sort after `c` (regardless of the numeric
component) although they are semantically equivalent. Tools are free to
reject this case as ambiguous and remain in compliance with the PEP.
Within an alpha (``1.0a1``), beta (``1.0b1``), or release candidate
(``1.0c1``, ``1.0rc1``), the following suffixes are permitted and are
ordered as shown::
.devN, <no suffix>, .postN
Within a post-release (``1.0.post1``), the following suffixes are permitted
and are ordered as shown::
devN, <no suffix>
Note that ``devN`` and ``postN`` must always be preceded by a dot, even
when used immediately following a numeric version (e.g. ``1.0.dev456``,
``1.0.post1``).
Within a given suffix, ordering is by the value of the numeric component.
The following example covers many of the possible combinations::
1.0.dev456
1.0a1
1.0a2.dev456
1.0a12.dev456
1.0a12
1.0b1.dev456
1.0b2
1.0b2.post345.dev456
1.0b2.post345
1.0c1.dev456
1.0c1
1.0
1.0.post456.dev34
1.0.post456
1.1.dev1
Version ordering across different metadata versions
---------------------------------------------------
Metadata v1.0 (PEP 241) and metadata v1.1 (PEP 314) do not
specify a standard version identification or ordering scheme. This PEP does
not mandate any particular approach to handling such versions, but
acknowledges that the de facto standard for ordering them is
the scheme used by the ``pkg_resources`` component of ``setuptools``.
Software that automatically processes distribution metadata may either
treat non-compliant version identifiers as an error, or attempt to normalize
them to the standard scheme. This means that projects using non-compliant
version identifiers may not be handled consistently across different tools,
even when correctly publishing the earlier metadata versions.
Distribution developers can help ensure consistent automated handling by
marking non-compliant versions as "hidden" on the Python Package Index
(removing them is generally undesirable, as users may be depending on
those specific versions being available).
Distribution users may also wish to remove non-compliant versions from any
private package indexes they control.
For metadata v1.2 (PEP 345), the version ordering described in this PEP
should be used in preference to the one defined in PEP 386.
Compatibility with other version schemes
----------------------------------------
Some projects may choose to use a version scheme which requires
translation in order to comply with the public version scheme defined in
this PEP. In such cases, the `Private-Version`__ field can be used to
record the project specific version as an arbitrary label, while the
translated public version is given in the `Version`_ field.
__ `Private-Version (optional)`_
This allows automated distribution tools to provide consistently correct
ordering of published releases, while still allowing developers to use
the internal versioning scheme they prefer for their projects.
Semantic versioning
~~~~~~~~~~~~~~~~~~~
`Semantic versioning`_ is a popular version identification scheme that is
more prescriptive than this PEP regarding the significance of different
elements of a release number. Even if a project chooses not to abide by
the details of semantic versioning, the scheme is worth understanding as
it covers many of the issues that can arise when depending on other
distributions, and when publishing a distribution that others rely on.
The "Major.Minor.Patch" (described in this PEP as "major.minor.micro")
aspects of semantic versioning (clauses 1-9 in the 2.0.0-rc-1 specification)
are fully compatible with the version scheme defined in this PEP, and abiding
by these aspects is encouraged.
Semantic versions containing a hyphen (pre-releases - clause 10) or a
plus sign (builds - clause 11) are *not* compatible with this PEP
and are not permitted in the public `Version`_ field.
One possible mechanism to translate such private semantic versions to
compatible public versions is to use the ``.devN`` suffix to specify the
appropriate version order.
.. _Semantic versioning: http://semver.org/
DVCS based version labels
~~~~~~~~~~~~~~~~~~~~~~~~~
Many build tools integrate with distributed version control systems like
Git and Mercurial in order to add an identifying hash to the version
identifier. As hashes cannot be ordered reliably such versions are not
permitted in the public `Version`_ field.
As with semantic versioning, the public ``.devN`` suffix may be used to
uniquely identify such releases for publication, while the private
version field is used to record the original version label.
Date based versions
~~~~~~~~~~~~~~~~~~~
As with other incompatible version schemes, date based versions can be
stored in the ``Private-Version`` field. Translating them to a compliant
version is straightforward: the simplest approach is to subtract the year
of the first release from the major component in the release number.
Version specifiers
==================
A version specifier consists of a series of version clauses, separated by
commas. Each version clause consists of an optional comparison operator
followed by a version identifier. For example::
0.9, >= 1.0, != 1.3.4, < 2.0
Each version identifier must be in the standard format described in
`Version scheme`_.
The comma (",") is equivalent to a logical **and** operator.
Comparison operators must be one of ``<``, ``>``, ``<=``, ``>=``, ``==``
or ``!=``.
The ``==`` and ``!=`` operators are strict - in order to match, the
version supplied must exactly match the specified version, with no
additional trailing suffix.
However, when no comparison operator is provided along with a version
identifier ``V``, it is equivalent to using the following pair of version
clauses::
>= V, < V+1
where ``V+1`` is the next version after ``V``, as determined by
incrementing the last numeric component in ``V`` (for example, if
``V == 1.0a3``, then ``V+1 == 1.0a4``, while if ``V == 1.0``, then
``V+1 == 1.1``).
This approach makes it easy to depend on a particular release series
simply by naming it in a version specifier, without requiring any
additional annotation. For example, the following pairs of version
specifiers are equivalent::
2
>= 2, < 3
3.3
>= 3.3, < 3.4
Whitespace between a conditional operator and the following version
identifier is optional, as is the whitespace around the commas.
Pre-releases of any kind, including developmental releases, are implicitly
excluded from all version specifiers, *unless* a pre-release or developmental
developmental release is explicitly mentioned in one of the clauses. For
example, this specifier implicitly excludes all pre-releases and development
releases of later versions::
>= 1.0
While these specifiers would include them::
>= 1.0a1
>= 1.0c1
>= 1.0, != 1.0b2
>= 1.0, < 2.0.dev123
Dependency resolution tools should use the above rules by default, but
should also allow users to request the following alternative behaviours:
* accept already installed pre-releases for all version specifiers
* retrieve and install available pre-releases for all version specifiers
Dependency resolution tools may also allow the above behaviour to be
controlled on a per-distribution basis.
Post-releases and purely numeric releases receive no special treatment -
they are always included unless explicitly excluded.
Given the above rules, projects which include the ``.0`` suffix for the
first release in a series, such as ``2.5.0``, can easily refer specifically
to that version with the clause ``2.5.0``, while the clause ``2.5`` refers
to that entire series. Projects which omit the ".0" suffix for the first
release of a series, by using a version string like ``2.5`` rather than
``2.5.0``, will need to use an explicit clause like ``>= 2.5, < 2.5.1`` to
refer specifically to that initial release.
Some examples:
* ``Requires-Dist: zope.interface (3.1)``: any version that starts with 3.1,
excluding pre-releases.
* ``Requires-Dist: zope.interface (==3.1)``: equivalent to ``Requires-Dist:
zope.interface (3.1)``.
* ``Requires-Dist: zope.interface (3.1.0)``: any version that starts with
3.1.0, excluding pre-releases. Since that particular project doesn't
use more than 3 digits, it also means "only the 3.1.0 release".
* ``Requires-Python: 3``: Any Python 3 version, excluding pre-releases.
* ``Requires-Python: >=2.6,<3``: Any version of Python 2.6 or 2.7, including
post-releases (if they were used for Python). It excludes pre releases of
Python 3.
* ``Requires-Python: 2.6.2``: Equivalent to ">=2.6.2,<2.6.3". So this includes
only Python 2.6.2. Of course, if Python was numbered with 4 digits, it would
include all versions of the 2.6.2 series, excluding pre-releases.
* ``Requires-Python: 2.5``: Equivalent to ">=2.5,<2.6".
* ``Requires-Dist: zope.interface (3.1,!=3.1.3)``: any version that starts
with 3.1, excluding pre-releases of 3.1 *and* excluding any version that
starts with "3.1.3". For this particular project, this means: "any version
of the 3.1 series but not 3.1.3". This is equivalent to:
">=3.1,!=3.1.3,<3.2".
* ``Requires-Python: >=3.3a1``: Any version of Python 3.3+, including
pre-releases like 3.4a1.
Depending on distributions that use non-compliant version schemes
-----------------------------------------------------------------
A distribution using this version of the metadata standard may need to depend
on another distribution using an earlier version of the metadata standard
and a non-compliant versioning scheme.
The normal ``Requires-Dist`` and ``Setup-Requires-Dist`` fields can be used
for such dependencies, so long as the dependency itself can be expressed
using a compliant version specifier.
For more exotic dependencies, a metadata extension would be needed in order
to express the dependencies accurately while still obeying the restrictions
on standard version specifiers. The ``Requires-External`` field may also
be used, but would not be as amenable to automatic processing.
Environment markers
===================
An **environment marker** is a marker that can be added at the end of a
field after a semi-colon (";"), to add a condition about the execution
environment.
Here are some example of fields using such markers::
Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
Requires-Dist: foo (1,!=1.3); platform.machine == 'i386'
Requires-Dist: bar; python_version == '2.4' or python_version == '2.5'
Requires-External: libxslt; 'linux' in sys.platform
The micro-language behind this is a simple subset of Python: it compares
only strings, with the ``==`` and ``in`` operators (and their opposites),
and with the ability to combine expressions. Parentheses are supported
for grouping.
The pseudo-grammar is ::
MARKER: EXPR [(and|or) EXPR]*
EXPR: ("(" MARKER ")") | (SUBEXPR [(in|==|!=|not in) SUBEXPR])
where ``SUBEXPR`` belongs to any of the following (the details after the
colon in each entry define the value represented by that subexpression):
* ``python_version``: '%s.%s' % (sys.version_info[0], sys.version_info[1])
* ``python_full_version``: sys.version.split()[0]
* ``os.name````: os.name
* ``sys.platform````: sys.platform
* ``platform.version``: platform.version()
* ``platform.machine``: platform.machine()
* ``platform.python_implementation``: = platform.python_implementation()
* ``extra``: (name of requested feature) or None
* ``'text'``: a free string, like ``'2.4'``, or ``'win32'``
Notice that ``in`` and ``not in`` are restricted to strings, meaning that it
is not possible to use other sequences like tuples or lists on the right
side.
The fields that benefit from this marker are:
* ``Requires-Python``
* ``Requires-External``
* ``Requires-Dist``
* ``Provides-Dist``
* ``Classifier``
Optional features
=================
Distributions may use the ``Provides-Extra`` field to declare additional
features that they provide. Environment markers may then be used to indicate
that particular dependencies are needed only when a particular optional
feature has been requested.
Other distributions then require an optional feature by placing it
inside square brackets after the distribution name when declaring the
dependency. Multiple features can be requisted by separating them with a
comma within the brackets.
The full set of dependency requirements is then the union of the sets
created by first evaluating the `Requires-Dist` fields with `extra`
set to `None` and then to the name of each requested feature.
Example::
Requires-Dist: beaglevote[pdf]
-> requires beaglevote, reportlab at run time
Setup-Requires-Dist: beaglevote[test, doc]
-> requires beaglevote, sphinx, nose at setup time
It is legal to specify `Provides-Extra` without referencing it in any
`Requires-Dist`. It is an error to request a feature name that has
not been declared with `Provides-Extra`.
The following feature names are implicitly defined for all distributions:
- `test`: dependencies that are needed in order to run automated tests
- `doc`: dependencies that are needed in order to generate documentation
Listing these implicit features explicitly in a ``Provides-Extra`` field is
permitted, but not required.
Updating the metadata specification
===================================
The metadata specification may be updated with clarifications without
requiring a new PEP or a change to the metadata version.
Adding new features (other than through the extension mechanism), or
changing the meaning of existing fields, requires a new metadata version
defined in a new PEP.
Summary of differences from \PEP 345
====================================
* Metadata-Version is now 2.0, with semantics specified for handling
version changes
* Most fields are now optional
* Explicit permission for in-place clarifications without releasing a new
version of the specification
* General reformatting of the PEP to make it easier to read
* Values are now expected to be UTF-8
* Changed the version scheme
* added the new ``Private-Version`` field
* changed the top level sort position of the ``.devN`` suffix
* allowed single value version numbers
* explicit exclusion of leading or trailing whitespace
* explicit criterion for the exclusion of date based versions
* incorporated the version scheme directly into the PEP
* Changed interpretation of version specifiers
* implicitly exclude pre-releases unless explicitly requested
* treat post releases the same way as unqualified releases
* Discuss ordering and dependencies across metadata versions
* Clarify use of parentheses for grouping in environment marker
pseudo-grammar
* Support for packaging, build and installation dependencies
* the new ``Setup-Requires-Dist`` field
* Optional feature mechanism
* the new ``Provides-Extra`` field
* ``extra`` expression defined for environment markers
* optional feature support in ``Requires-Dist``
* Metadata extension mechanism
* the new ``Extension`` field and extension specific fields
* Updated obsolescence mechanism
* the new ``Obsoleted-By`` field
* the ``Obsoletes-Dist`` field has been removed
* Simpler description format
* the ``Description`` field is now deprecated
* A payload (containing the description) may appear after the headers.
* Other changed fields:
- ``Requires-Python`` (explicitly flagged as multiple use)
- ``Project-URL`` (commas permitted in labels)
* Clarified fields:
- ``Provides-Dist``
- ``Keywords``
The rationale for major changes is given in the following sections.
Metadata-Version semantics
--------------------------
The semantics of major and minor version increments are now specified,
and follow the same model as the format version semantics specified for
the wheel format in PEP 427: minor version increments must behave
reasonably when processed by a tool that only understand earlier metadata
versions with the same major version, while major version increments
may include changes that are not compatible with existing tools.
The major version number of the specification has been incremented
accordingly, as interpreting PEP 426 metadata in accordance with earlier
metadata specifications is unlikely to give the expected behaviour.
Whenever the major version number of the specification is incremented, it
is expected that deployment will take some time, as metadata consuming tools
much be updated before other tools can safely start producing the new
format.
Standard encoding and other format clarifications
-------------------------------------------------
Several aspects of the file format, including the expected file encoding,
were underspecified in previous versions of the metadata standard. To
make it easier to develop interoperable tools, these details are now
explicitly specified.
Changing the version scheme
---------------------------
The new ``Private-Version`` field is intended to make it clearer that the
constraints on public version identifiers are there primarily to aid in
the creation of reliable automated dependency analysis tools. Projects
are free to use whatever versioning scheme they like internally, so long
as they are able to translate it to something the dependency analysis tools
will understand.
The key change in the version scheme in this PEP relative to that in
PEP 386 is to sort top level developmental releases like ``X.Y.devN`` ahead
of alpha releases like ``X.Ya1``. This is a far more logical sort order, as
projects already using both development releases and alphas/betas/release
candidates do not want their developmental releases sorted in
between their release candidates and their full releases. There is no
rationale for using ``dev`` releases in that position rather than
merely creating additional release candidates.
The updated sort order also means the sorting of ``dev`` versions is now
consistent between the metadata standard and the pre-existing behaviour
of ``pkg_resources`` (and hence the behaviour of current installation
tools).
Making this change should make it easier for affected existing projects to
migrate to the latest version of the metadata standard.
Another change to the version scheme is to allow single number
versions, similar to those used by non-Python projects like Mozilla
Firefox, Google Chrome and the Fedora Linux distribution. This is actually
expected to be more useful for version specifiers (allowing things like
the simple ``Requires-Python: 3`` rather than the more convoluted
``Requires-Python: >= 3.0, < 4``), but it is easier to allow it for both
version specifiers and release numbers, rather than splitting the
two definitions.
The exclusion of leading and trailing whitespace was made explicit after
a couple of projects with version identifiers differing only in a
trailing ``\n`` character were found on PyPI.
The exclusion of major release numbers that looks like dates was implied
by the overall text of PEP 386, but not clear in the definition of the
version scheme. This exclusion has been made clear in the definition of
the release component.
Finally, as the version scheme in use is dependent on the metadata
version, it was deemed simpler to merge the scheme definition directly into
this PEP rather than continuing to maintain it as a separate PEP. This will
also allow all of the distutils-specific elements of PEP 386 to finally be
formally rejected.
The following statistics provide an analysis of the compatibility of existing
projects on PyPI with the specified versioning scheme (as of 16th February,
2013).
* Total number of distributions analysed: 28088
* Distributions with no releases: 248 / 28088 (0.88 %)
* Fully compatible distributions: 24142 / 28088 (85.95 %)
* Compatible distributions after translation: 2830 / 28088 (10.08 %)
* Compatible distributions after filtering: 511 / 28088 (1.82 %)
* Distributions sorted differently after translation: 38 / 28088 (0.14 %)
* Distributions sorted differently without translation: 2 / 28088 (0.01 %)
* Distributions with no compatible releases: 317 / 28088 (1.13 %)
The two remaining sort order discrepancies picked up by the analysis are due
to a pair of projects which have published releases ending with a carriage
return, alongside releases with the same version number, only *without* the
trailing carriage return.
The sorting discrepancies after translation relate mainly to differences
in the handling of pre-releases where the standard mechanism is considered
to be an improvement. For example, the existing pkg_resources scheme will
sort "1.1beta1" *after* "1.1b2", whereas the suggested standard translation
for "1.1beta1" is "1.1b1", which sorts *before* "1.1b2". Similarly, the
pkg_resources scheme will sort "-dev-N" pre-releases differently from
"devN" pre-releases when they occur within the same release, while the
standard scheme will normalize both representations to ".devN" and sort
them by the numeric component.
For comparison, here are the corresponding analysis results for PEP 386:
* Total number of distributions analysed: 28088
* Distributions with no releases: 248 / 28088 (0.88 %)
* Fully compatible distributions: 23874 / 28088 (85.00 %)
* Compatible distributions after translation: 2786 / 28088 (9.92 %)
* Compatible distributions after filtering: 527 / 28088 (1.88 %)
* Distributions sorted differently after translation: 96 / 28088 (0.34 %)
* Distributions sorted differently without translation: 14 / 28088 (0.05 %)
* Distributions with no compatible releases: 543 / 28088 (1.93 %)
These figures make it clear that only a relatively small number of current
projects are affected by these changes. However, some of the affected
projects are in widespread use (such as Pinax and selenium). The
changes also serve to bring the standard scheme more into line with
developer's expectations, which is an important element in encouraging
adoption of the new metadata version.
The script used for the above analysis is available at [3]_.
A more opinionated description of the versioning scheme
-------------------------------------------------------
As in PEP 386, the primary focus is on codifying existing practices to make
them more amenable to automation, rather than demanding that existing
projects make non-trivial changes to their workflow. However, the
standard scheme allows significantly more flexibility than is needed
for the vast majority of simple Python packages (which often don't even
need maintenance releases - many users are happy with needing to upgrade to a
new feature release to get bug fixes).
For the benefit of novice developers, and for experienced developers
wishing to better understand the various use cases, the specification
now goes into much greater detail on the components of the defined
version scheme, including examples of how each component may be used
in practice.
The PEP also explicitly guides developers in the direction of
semantic versioning (without requiring it), and discourages the use of
several aspects of the full versioning scheme that have largely been
included in order to cover esoteric corner cases in the practices of
existing projects and in repackaging software for Linux distributions.
Changing the interpretation of version specifiers
-------------------------------------------------
The previous interpretation of version specifiers made it very easy to
accidentally download a pre-release version of a dependency. This in
turn made it difficult for developers to publish pre-release versions
of software to the Python Package Index, as leaving the package set as
public would lead to users inadvertently downloading pre-release software,
while hiding it would defeat the purpose of publishing it for user
testing.
The previous interpretation also excluded post-releases from some version
specifiers for no adequately justified reason.
The updated interpretation is intended to make it difficult to accidentally
accept a pre-release version as satisfying a dependency, while allowing
pre-release versions to be explicitly requested when needed.
Packaging, build and installation dependencies
----------------------------------------------
The new ``Setup-Requires-Dist`` field allows a distribution to indicate when
a dependency is needed to package, build or install the distribution, rather
than being needed to run the software after installation.
This should allow distribution tools to effectively support a wider range of
distribution requirements.
Support for optional features of distributions
----------------------------------------------
The new ``Provides-Extra`` field allows distributions to declare optional
features, and to use environment markers to reduce their dependencies
when those features are not requested. Environment markers may also be
used to require a later version of Python when particular features are
requested.
The ``Requires-Dist`` and ``Setup-Requires-Dist`` fields then allow
distributions to require optional features of other distributions.
The ``test`` and ``doc`` features are implicitly defined for all
distributions, as one key motivation for this feature is to encourage
distributions to explicitly declare the dependencies needed to run
their automatic tests, or build their documentation, without demanding those
dependencies be present in order to merely install or use the software.
Support for metadata extensions
-------------------------------
The new ``Extension`` field effectively allows sections of the metadata
namespace to be delegated to other distributions, while preserving a
standard overal format metadata format for easy of processing by
distribution tools that do not support a particular extension.
It also works well in combination with the new ``Setup-Requires-Dist`` field
to allow a distribution to depend on tools which *do* know how to handle
the chosen extension, and the new optional features mechanism, allowing
support for particular extensions to be provided as optional features.
Updated obsolescence mechanism
------------------------------
The marker to indicate when a project is obsolete and should be replaced
has been moved to the obsolete project (the new ``Obsoleted-By`` field),
replacing the previous marker on the replacement project (the removed
``Obsoletes-Dist`` field).
This should allow distribution tools to more easily warn users of
obsolete projects and their suggested replacements.
The ``Obsoletes-Dist`` header is removed rather than deprecated as it
is not widely supported, and so removing it does not present any significant
barrier to tools and projects adopting the new metadata format.
Simpler description format
--------------------------
Distribution descriptions are often quite long, sometimes including a
short guide to using the module. Moving them into the file payload allows
them to be formatted neatly as reStructuredText without needing to
carefully avoid the introduction of a blank line that would terminate
the header section.
The ``Description`` header is deprecated rather than removed to support
easier conversion of existing tools and projects to the new metadata
format.
References
==========
This document specifies version 2.0 of the metadata format.
Version 1.0 is specified in PEP 241.
Version 1.1 is specified in PEP 314.
Version 1.2 is specified in PEP 345.
The initial attempt at a standardised version scheme, along with the
justifications for needing such a standard can be found in PEP 386.
.. [1] reStructuredText markup:
http://docutils.sourceforge.net/
.. _`Python Package Index`: http://pypi.python.org/pypi/
.. [2] PEP 301:
http://www.python.org/dev/peps/pep-0301/
.. [3] Version compatibility analysis script:
http://hg.python.org/peps/file/default/pep-0426/pepsort.py
Appendix
========
Parsing and generating the Metadata 2.0 serialization format using
Python 3.3::
# Metadata 2.0 demo
from email.generator import Generator
from email import header
from email.parser import Parser
from email.policy import Compat32
from email.utils import _has_surrogates
class MetadataPolicy(Compat32):
max_line_length = 0
continuation_whitespace = '\t'
def _sanitize_header(self, name, value):
if not isinstance(value, str):
return value
if _has_surrogates(value):
raise NotImplementedError()
else:
return value
def _fold(self, name, value, sanitize):
body = ((self.linesep+self.continuation_whitespace)
.join(value.splitlines()))
return ''.join((name, ': ', body, self.linesep))
if __name__ == "__main__":
import sys
import textwrap
pkg_info = """\
Metadata-Version: 2.0
Name: package
Version: 0.1.0
Summary: A package.
Description: Description
===========
A description of the package.
"""
m = Parser(policy=MetadataPolicy()).parsestr(pkg_info)
m['License'] = 'GPL'
description = m['Description']
description_lines = description.splitlines()
m.set_payload(description_lines[0]
+ '\n'
+ textwrap.dedent('\n'.join(description_lines[1:]))
+ '\n')
del m['Description']
# Correct if sys.stdout.encoding == 'UTF-8':
Generator(sys.stdout, maxheaderlen=0).flatten(m)
Copyright
=========
This document has been placed in the public domain.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
[View Less]
12
42