[Python-Dev] AUTO: Jon K Peck is out of the office
I am out of the office until 09/17/2012. I will be out of the office from Sept 14 through Sept 16. I will not have email access during this time. Note: This is an automated response to your message "Python-Dev Digest, Vol 110, Issue 24" sent on 09/14/2012 4:00:03. This is the only notification you will receive while this person is away.___ 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] packaging location ?
Nick Coghlan gmail.com> writes: > > I like "distcore" or "distlib", though. > I have set up a BitBucket repo called distlib, at https://bitbucket.org/vinay.sajip/distlib/ This has the following bits of distutils2 / packaging, updated to run on 2.x and 3.x with a single codebase, and including tests (though not docs, yet): version.py - version specifiers as per PEP 386 metadata.py - metadata as per PEPs 345, 314 and 241 markers.py - environment markers as per PEP 345 database.py - installed distributions as per PEP 376 depgraph.py - distribution dependency graph logic glob.py - globbing functionality The code was taken at around the time packaging was removed, and may not have more recent changes. Regards, Vinay Sajip ___ 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-09-07 - 2012-09-14) 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: open3701 (+20) closed 24020 (+45) total 27721 (+65) Open issues with patches: 1637 Issues opened (46) == #15880: os.path.split() and long UNC names http://bugs.python.org/issue15880 opened by kaba2 #15881: multiprocessing 'NoneType' object is not callable http://bugs.python.org/issue15881 opened by mcdonc #15882: _decimal.Decimal constructed from tuple http://bugs.python.org/issue15882 opened by hac.man #15883: Add Py_errno to work around multiple CRT issue http://bugs.python.org/issue15883 opened by christian.heimes #15884: PEP 3121, 384 Refactoring applied to ctypes module http://bugs.python.org/issue15884 opened by belopolsky #15887: urlencode should accept generators or two elements tuples http://bugs.python.org/issue15887 opened by nagisa #15888: ipaddress doctest examples have some errors http://bugs.python.org/issue15888 opened by cjerdonek #15889: regrtest --start option raises AttributeError in many scenario http://bugs.python.org/issue15889 opened by cjerdonek #15890: lib2to3 pickles created with wrong permissions http://bugs.python.org/issue15890 opened by tpievila #15892: _PyImport_GetDynLoadFunc() doesn't check return value of fstat http://bugs.python.org/issue15892 opened by christian.heimes #15893: Py_FrozenMain() resource leak and missing malloc checks http://bugs.python.org/issue15893 opened by christian.heimes #15894: _PyImport_ReInitLock() doesn't check return value of PyThread_ http://bugs.python.org/issue15894 opened by christian.heimes #15895: PyRun_SimpleFileExFlags() can leak a FILE pointer http://bugs.python.org/issue15895 opened by christian.heimes #15896: Sporadic EINVAL in nonblocking pipe os.read when forked child http://bugs.python.org/issue15896 opened by vitaly #15897: zipimport.c doesn't check return value of fseek() http://bugs.python.org/issue15897 opened by christian.heimes #15898: OSX TTY bug http://bugs.python.org/issue15898 opened by amoffat #15900: Memory leak in PyUnicode_TranslateCharmap() http://bugs.python.org/issue15900 opened by christian.heimes #15902: imp.load_module won't accept None for the file argument for a http://bugs.python.org/issue15902 opened by pmoore #15903: Make rawiobase_read() read directly to bytes object http://bugs.python.org/issue15903 opened by sbt #15904: file,close() can fail assert on Windows in 2.7 http://bugs.python.org/issue15904 opened by sbt #15905: Copy to fixed size buffer w/o check in sys_update_path http://bugs.python.org/issue15905 opened by christian.heimes #15907: move doctest test-data files into a subdirectory of Lib/test http://bugs.python.org/issue15907 opened by cjerdonek #15911: can't step through _frozen_importlib/importlib._bootstrap usin http://bugs.python.org/issue15911 opened by exarkun #15913: PyBuffer_SizeFromFormat is missing http://bugs.python.org/issue15913 opened by ellery.newcomer #15914: multiprocessing.SyncManager connection hang http://bugs.python.org/issue15914 opened by palmer #15916: change doctest DocTestSuite not to raise ValueError if no docs http://bugs.python.org/issue15916 opened by cjerdonek #15917: hg hook to detect unmerged changesets http://bugs.python.org/issue15917 opened by ezio.melotti #15918: subprocess.Popen reads errpipe_read incorrectly, can result in http://bugs.python.org/issue15918 opened by vitaly #15919: hg.python.org: log page entries don't always link to revision http://bugs.python.org/issue15919 opened by cjerdonek #15920: make howto/regex.rst doctests pass http://bugs.python.org/issue15920 opened by cjerdonek #15922: make howto/urllib2.rst doctests pass http://bugs.python.org/issue15922 opened by cjerdonek #15923: Building from a fresh clone breaks on Parser/asdl_c.py http://bugs.python.org/issue15923 opened by barry #15925: email.utils.parsedate(), email.utils.parsedate_tz() and email. http://bugs.python.org/issue15925 opened by Arfrever #15926: Segmentation fault after multiple reinitializations http://bugs.python.org/issue15926 opened by Arfrever #15927: csv.reader() does not support escaped newline when quoting=csv http://bugs.python.org/issue15927 opened by kalaxy #15931: inspect.findsource fails after directory change http://bugs.python.org/issue15931 opened by kgabor79 #15932: files in the csv documentation's examples are not closed http://bugs.python.org/issue15932 opened by berdario #15933: flaky test in test_datetime http://bugs.python.org/issue15933 opened by pitrou #15934: flaky test in test_ftplib http://bugs.python.org/issue15934 opened by pitrou #15935: clarify argparse docs re: add_argument() type and default argu http://bugs.python.org/issue15935 opened by cjerdonek #15936: Add link from os.urandom to random.SystemRandom http://bu
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
Add to metadata 1.3: Description-File: README(\..+)? Meaning the description should be read from a file in the same directory as PKG-INFO or METADATA (including in the .dist-info directories) and we strongly recommend it be named as README.* and be utf-8 encoded text. Description: is the only multi-line field in the metadata. It is almost never needed at runtime. It would be great for performance and simplify the parser to just put it in another file. Mutually exclusive with Description. May beg for a Summary: tag with a one-line description. ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Fri, Sep 14, 2012 at 12:30 PM, Daniel Holth wrote: > Add to metadata 1.3: > > Description-File: README(\..+)? > > Meaning the description should be read from a file in the same > directory as PKG-INFO or METADATA (including in the .dist-info > directories) and we strongly recommend it be named as README.* and be > utf-8 encoded text. > > Description: is the only multi-line field in the metadata. It is > almost never needed at runtime. It would be great for performance and > simplify the parser to just put it in another file. > > Mutually exclusive with Description. > > May beg for a Summary: tag with a one-line description. Can we make Description-File multiple-use? The meaning of this would be that the Description is formed from concatenating each Description-File in order. That raises the question: Is ordering guaranteed for multiple-use fields? I ask, because distutils2 supports exactly such a feature, and I've found it useful. For example, if I have a README.rst and a CHANGELOG.rst I can specify: description-file = README.rst CHANGELOG.rst Then the full description, contains my readme and my changelog, which look nice together on PyPI, but I prefer to keep as separate files in the source. My only other concern is that if the value of this field can theoretically be arbitrary, it could conflict with other .dist-info files. Does the .dist-info format allow subdirectories? Placing description-files in a subdirectory of .dist-info could be a reasonable workaround. Erik ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Friday, September 14, 2012 at 12:30 PM, Daniel Holth wrote: > Add to metadata 1.3: > > Description-File: README(\..+)? > > Meaning the description should be read from a file in the same > directory as PKG-INFO or METADATA (including in the .dist-info > directories) and we strongly recommend it be named as README.* and be > utf-8 encoded text. > > Description: is the only multi-line field in the metadata. It is > almost never needed at runtime. It would be great for performance and > simplify the parser to just put it in another file. > > Mutually exclusive with Description. > > May beg for a Summary: tag with a one-line description. > ___ > Python-Dev mailing list > [email protected] (mailto:[email protected]) > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com > > -1 on this personally ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Fri, Sep 14, 2012 at 1:43 PM, Erik Bray wrote: > On Fri, Sep 14, 2012 at 12:30 PM, Daniel Holth wrote: >> Add to metadata 1.3: >> >> Description-File: README(\..+)? >> >> Meaning the description should be read from a file in the same >> directory as PKG-INFO or METADATA (including in the .dist-info >> directories) and we strongly recommend it be named as README.* and be >> utf-8 encoded text. >> >> Description: is the only multi-line field in the metadata. It is >> almost never needed at runtime. It would be great for performance and >> simplify the parser to just put it in another file. >> >> Mutually exclusive with Description. >> >> May beg for a Summary: tag with a one-line description. > > Can we make Description-File multiple-use? The meaning of this would > be that the Description is formed from concatenating each > Description-File in order. That raises the question: Is ordering > guaranteed for multiple-use fields? > > I ask, because distutils2 supports exactly such a feature, and I've > found it useful. For example, if I have a README.rst and a > CHANGELOG.rst I can specify: > > description-file = > README.rst > CHANGELOG.rst > > Then the full description, contains my readme and my changelog, which > look nice together on PyPI, but I prefer to keep as separate files in > the source. > > My only other concern is that if the value of this field can > theoretically be arbitrary, it could conflict with other .dist-info > files. Does the .dist-info format allow subdirectories? Placing > description-files in a subdirectory of .dist-info could be a > reasonable workaround. > > Erik The .dist-info design asks for every metadata file (the one in all caps, not any of the other metadata in .dist-info) to be parsed for many packaging operations that do not require the description, such as resolving the dependency graph of a package. Description-File would give an installer the option to pull Description: out into Description-File:. I would expect the concatenation to happen before this point. I would like to forbid subdirectories in .dist-info but I think they are allowed. The order of multi-use fields is probably preserved. I don't think it is required to be by any spec. ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Friday, September 14, 2012 at 12:30 PM, Daniel Holth wrote: > Description: is the only multi-line field in the metadata. It is > almost never needed at runtime. It would be great for performance and > simplify the parser to just put it in another file. License also can be multiline I believe, ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Fri, Sep 14, 2012 at 2:03 PM, Donald Stufft wrote: > On Friday, September 14, 2012 at 12:30 PM, Daniel Holth wrote: > > Description: is the only multi-line field in the metadata. It is > almost never needed at runtime. It would be great for performance and > simplify the parser to just put it in another file. > > License also can be multiline I believe, OK. In practice, Description: is the only field that is likely to be hundreds of lines long which seems wasteful. The parser complexity is a non-issue. (I know the PEP says Description: should not be the instruction manual, but it is wrong because that is the way to get useful data up on a package's pypi page.) ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On 14 September 2012 17:30, Daniel Holth wrote:
> we strongly recommend it be named as README.* and be
> utf-8 encoded text.
I'd very strongly recommend that the encoding should be mandated. I'm
happy with UTF-8 (although I expect a lot of "accidental" latin-1
files, particularly from Windows users) but I think it would be a
mistake to have the specification leaving the encoding of *any* string
data unclear. Without the encoding being specified, either in the
metadata itself ("Description-File-Encoding: utf8"? Please, no) or by
the specification mandating it, how is a program expected to read the
description?
Other than this point, I have no opinion on the proposal.
Paul.
___
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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Fri, Sep 14, 2012 at 1:57 PM, Daniel Holth wrote: > On Fri, Sep 14, 2012 at 1:43 PM, Erik Bray wrote: >> On Fri, Sep 14, 2012 at 12:30 PM, Daniel Holth wrote: >>> Add to metadata 1.3: >>> >>> Description-File: README(\..+)? >>> >>> Meaning the description should be read from a file in the same >>> directory as PKG-INFO or METADATA (including in the .dist-info >>> directories) and we strongly recommend it be named as README.* and be >>> utf-8 encoded text. >>> >>> Description: is the only multi-line field in the metadata. It is >>> almost never needed at runtime. It would be great for performance and >>> simplify the parser to just put it in another file. >>> >>> Mutually exclusive with Description. >>> >>> May beg for a Summary: tag with a one-line description. >> >> Can we make Description-File multiple-use? The meaning of this would >> be that the Description is formed from concatenating each >> Description-File in order. That raises the question: Is ordering >> guaranteed for multiple-use fields? >> >> I ask, because distutils2 supports exactly such a feature, and I've >> found it useful. For example, if I have a README.rst and a >> CHANGELOG.rst I can specify: >> >> description-file = >> README.rst >> CHANGELOG.rst >> >> Then the full description, contains my readme and my changelog, which >> look nice together on PyPI, but I prefer to keep as separate files in >> the source. >> >> My only other concern is that if the value of this field can >> theoretically be arbitrary, it could conflict with other .dist-info >> files. Does the .dist-info format allow subdirectories? Placing >> description-files in a subdirectory of .dist-info could be a >> reasonable workaround. >> >> Erik > > The .dist-info design asks for every metadata file (the one in all > caps, not any of the other metadata in .dist-info) to be parsed for > many packaging operations that do not require the description, such as > resolving the dependency graph of a package. Description-File would > give an installer the option to pull Description: out into > Description-File:. I would expect the concatenation to happen before > this point. I understand now. In this case why even allow flexibility in the description file name? Just make it description.txt, and the Description-File field just some boolean indicator of whether or not a description file exists? Erik ___ 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] What's New in Python 3.3: missing unittest.mock!
Hi, I just noticed that the new unittest.mock module is missing from the What's New in Python 3.3. Can someone add it? (I cannot right now). Thanks. Victor ___ 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
