Re: [Python-Dev] PEP 431 Time zone support improvements - Update
On 30Dec2012 07:42, Lennart Regebro wrote: | On Sat, Dec 29, 2012 at 11:55 PM, Cameron Simpson wrote: | | > On 29Dec2012 21:16, Lennart Regebro wrote: | > | On Sat, Dec 29, 2012 at 8:04 PM, Antoine Pitrou | > wrote: | > | > Why should we care about that situation if we *do* provide a database? | > | > Distributions can decide to exclude some files from their packages, but | > | > it's their problem, not ours. | > | | > | Yes, but a comprehensible error message is useful even if somebody messed | > | up the system/configuration. | > | > Couldn't you just agree to augument the exception with some "I looked | > here, there and there" information. It avoids a lot of bikeshedding and | > makes things clear. You're not diagnosing system misconfiguration, just | > saying "I can't find stuff, and here is where I looked". | | Since the location of the tzdata-update package isn't a fixed place it's | hard to say "I looked here, there and there", though. I don't think anyone | has suggested making any diagnostics. :-) I think I misunderstood the context. Never mind. -- Cameron Simpson Displays are sold by the acre, not the function. - overhead by WIRED at the Intelligent Printing conference Oct2006 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP for time zone support.
On 29/12/12 15:40, Lennart Regebro wrote: On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Apranowrote: The PEP says: * New function :``timezone(name=None, db_path=None)`` This function takes a name string that must be a string specifying a valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11". It isn't 100% clear to me from the PEP what a valid name string would be, but I assume that it will accept anything that the time.tzset function will accept: No, valid names are the names of time zones in the zoneinfo database. If I've understood it correctly, that contradicts the PEP. One example given is "Etc/GMT+11", which is not a timezone *name*, but a timezone name *plus an offset*. Presumably if GMT+11 is legal, so should be GMT+10:30. There is no "Etc/GMT+11" named here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones nor is it included in /usr/share/zoneinfo/zone.tab in either of the systems I looked at (one Debian, one Centos), but there is Etc/GMT. So I conclude that the PEP allows timezone rules, not just names. Either way, I think the PEP needs to clarify what counts as a valid name string. There isn't really any usecase for defining up your own rules as that would mean that you want a time zone that doesn't exist, which seems a bit pointless. :-) It means you want a time zone that doesn't exist in the database, which is not the same as not existing in real life. Perhaps the database is out-of-date, or the government has suddenly declared a daylight savings change that isn't reflected yet in the database. Or you want to set your own TZ rules for testing. Or you've just declared independence from the central government and are setting up your own TZ rules. time.tzset supports rules as well as names. Is there some reason why this module should not do the same? I also quote from /usr/share/doc/tzdata-2012f/README on my Centos system: [quote] README for the tz distribution [...] The 1989 update of the time zone package featured [...] * reference data from the United States Naval Observatory for folks who want to do additional time zones [end quote] So the people who prepare tzdata on Red Hat systems clearly think that there are use-cases for making additional time zones. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 431 Time zone support improvements - Update
On 29 Dec, 2012, at 5:48, Lennart Regebro wrote: > On Fri, Dec 28, 2012 at 10:12 PM, Ronald Oussoren > wrote: > > On 28 Dec, 2012, at 21:23, Lennart Regebro wrote: > > > Happy Holidays! Here is the update of PEP 431 with the changes that emerged > > after the earlier discussion. > > Why is the new timezone support added in a submodule of datetime? > > Because several people wanted it that way and nobody objected. > > Adding the new > function and exception to datetime itself wouldn't clutter the API that much > > It will make the datetime.py twice as long though, and the second longest > module in the stdlib, beaten only by decimal.py. Perhaps this is not a > problem. The module could be split into several modules in a package without affecting the public API if that would help with maintenance, simular to unittest. Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
On 30/12/2012 12:31am, Eli Bendersky wrote: Would it make sense to save the sys.modules state and restore it in test___all__ so that sys.modules isn't affected by this test? Deleting module objects can cause problems because the destructor replaces values in the globals dict by None. If anything defined there has "escaped" and depends on any globals then you are liable to encounter errors. For example, setuptools restores sys.modules after running each test. This was causing errors at shutdown from an atexit function registered by multiprocessing. The atexit function was still registered, but no longer valid, because the module had been garbage collected and the globals had been replaced by None. Personally I would like to get rid of the "purge globals" behaviour for modules deleted before shutdown has started: if someone manipulates sys.modules then they can just call gc.collect() if they want to promptly get rid of orphaned reference cycles. -- Richard ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
On Sat, Dec 29, 2012 at 5:34 PM, Nick Coghlan wrote: > On Sun, Dec 30, 2012 at 10:46 AM, Benjamin Peterson > wrote: > > 2012/12/29 Eli Bendersky : > >> Hi, > >> > >> This came up while investigating some test-order-dependency failures in > >> issue 16076. > >> > >> test___all__ goes over modules that have `__all__` in them and does > 'from > >> import *' on them. This leaves a lot of modules in sys.modules, > >> which may interfere with some tests that do fancy things with > sys,modules. > >> In particular, the ElementTree tests have trouble with it because they > >> carefully set up the imports to get the C or the Python version of etree > >> (see issues 15083 and 15075). > >> > >> Would it make sense to save the sys.modules state and restore it in > >> test___all__ so that sys.modules isn't affected by this test? > > > > Sounds reasonable to me. > > I've tried this as an inherent property of regrtest before (to resolve > some problems with test_pydoc), and it didn't work - we have too many > modules with non-local side effects (IIRC, mostly related to the copy > and pickle registries). > > Given that it checks the whole standard library, test___all__ is > likely to run into the same problem. > > Yes, I'm running into all kinds of weird problems when saving/restoring sys.modules around test___all__. This is not the first time I get to fight this test-run-dependency problem and it's very frustrating. This may be a naive question, but why don't we run the tests in separate interpreters? For example with -j we do (which creates all kinds of strange intermittent problems depending on which tests got bundled into the same process). Is this a matter of performance? Because that would help get rid of these dependencies between tests, which would probably save core devs some work and headache. After all, since a lot of the interpreter state is global (for example sys.modules), does it not make sense to run each test in a clean environment? Many tests do fancy things with the global environment which makes them difficult to keep clean and separate. > Hence test.support.import_fresh_module - it can ensure you get the > module you want, regardless of the preexisting contents of > sys.modules. ( > http://docs.python.org/dev/library/test#test.support.import_fresh_module) > Yes, this is the solution currently used in test_xml_etree. However, once pickling tests are added things stop working. Pickle uses __import__ to import the module a class belongs to, bypassing all such trickery. So if test___all__ got _elementtree into sys.modules, pickle's __import__ finds it even if all the tests in test_xml_etree manage to ignore it for the Python version because they use import_fresh_module. Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
Eli Bendersky wrote: > Yes, this is the solution currently used in test_xml_etree. However, once > pickling tests are added things stop working. Pickle uses __import__ to import > the module a class belongs to, bypassing all such trickery. So if test___all__ > got _elementtree into sys.modules, pickle's __import__ finds it even if all > the > tests in test_xml_etree manage to ignore it for the Python version because > they > use import_fresh_module. I ran into the same problem for test_decimal. The only thing that appears to work is to set sys.modules['decimal'] explicitly before calling dumps()/loads(). See: PythonAPItests.test_pickle() ContextAPItests.test_pickle() test_decimal ruthlessly switches sys.modules['decimal'] many times. At the end of all tests there is a sanity check that asserts that the number of changes were in fact balanced. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote: > Eli Bendersky wrote: > > Yes, this is the solution currently used in test_xml_etree. However, once > > pickling tests are added things stop working. Pickle uses __import__ to > import > > the module a class belongs to, bypassing all such trickery. So if > test___all__ > > got _elementtree into sys.modules, pickle's __import__ finds it even if > all the > > tests in test_xml_etree manage to ignore it for the Python version > because they > > use import_fresh_module. > > I ran into the same problem for test_decimal. The only thing that appears > to work is to set sys.modules['decimal'] explicitly before calling > dumps()/loads(). See: > >PythonAPItests.test_pickle() >ContextAPItests.test_pickle() > > > test_decimal ruthlessly switches sys.modules['decimal'] many times. At the > end of all tests there is a sanity check that asserts that the number of > changes were in fact balanced. Thank you, I'll try this. I'm also experimenting with other approaches. By the way, from clean default checkout: $ ./python -mtest test___all__ test_int [1/2] test___all__ [2/2] test_int test test_int failed -- Traceback (most recent call last): File "/home/eliben/python-src/default/Lib/test/test_int.py", line 236, in test_keyword_args self.assertRaises(TypeError, int, base=10) AssertionError: TypeError not raised by int 1 test OK. 1 test failed: test_int Should this really fail? [I haven't investigated the root cause yet] Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
On Sun, Dec 30, 2012 at 6:06 AM, Eli Bendersky wrote: > > > > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote: > >> Eli Bendersky wrote: >> > Yes, this is the solution currently used in test_xml_etree. However, >> once >> > pickling tests are added things stop working. Pickle uses __import__ to >> import >> > the module a class belongs to, bypassing all such trickery. So if >> test___all__ >> > got _elementtree into sys.modules, pickle's __import__ finds it even if >> all the >> > tests in test_xml_etree manage to ignore it for the Python version >> because they >> > use import_fresh_module. >> >> I ran into the same problem for test_decimal. The only thing that appears >> to work is to set sys.modules['decimal'] explicitly before calling >> dumps()/loads(). See: >> >>PythonAPItests.test_pickle() >>ContextAPItests.test_pickle() >> >> >> test_decimal ruthlessly switches sys.modules['decimal'] many times. At the >> end of all tests there is a sanity check that asserts that the number of >> changes were in fact balanced. > > > Thank you, I'll try this. I'm also experimenting with other approaches. > > By the way, from clean default checkout: > > $ ./python -mtest test___all__ test_int > [1/2] test___all__ > [2/2] test_int > test test_int failed -- Traceback (most recent call last): > File "/home/eliben/python-src/default/Lib/test/test_int.py", line 236, > in test_keyword_args > self.assertRaises(TypeError, int, base=10) > AssertionError: TypeError not raised by int > > 1 test OK. > 1 test failed: > test_int > > Should this really fail? [I haven't investigated the root cause yet] > This is a false alarm, sorry. Please ignore this report (I had some stale build artifacts). Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote: > Eli Bendersky wrote: > > Yes, this is the solution currently used in test_xml_etree. However, once > > pickling tests are added things stop working. Pickle uses __import__ to > import > > the module a class belongs to, bypassing all such trickery. So if > test___all__ > > got _elementtree into sys.modules, pickle's __import__ finds it even if > all the > > tests in test_xml_etree manage to ignore it for the Python version > because they > > use import_fresh_module. > > I ran into the same problem for test_decimal. The only thing that appears > to work is to set sys.modules['decimal'] explicitly before calling > dumps()/loads(). See: > >PythonAPItests.test_pickle() >ContextAPItests.test_pickle() > > Yes, this seems to have done the trick. Thanks for the suggestion. I'm still curious about the test-in-clean-env question though. Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
Eli Bendersky wrote: > Yes, this seems to have done the trick. Thanks for the suggestion. > > I'm still curious about the test-in-clean-env question though. I think that in general we do want to check unexpected interactions between tests, that's also why the test order is randomized. Here's an example that might not have been caught with clean-env tests: http://bugs.python.org/issue7384 Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky wrote: > > > > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote: >> >> Eli Bendersky wrote: >> > Yes, this is the solution currently used in test_xml_etree. However, >> > once >> > pickling tests are added things stop working. Pickle uses __import__ to >> > import >> > the module a class belongs to, bypassing all such trickery. So if >> > test___all__ >> > got _elementtree into sys.modules, pickle's __import__ finds it even if >> > all the >> > tests in test_xml_etree manage to ignore it for the Python version >> > because they >> > use import_fresh_module. >> >> I ran into the same problem for test_decimal. The only thing that appears >> to work is to set sys.modules['decimal'] explicitly before calling >> dumps()/loads(). See: >> >>PythonAPItests.test_pickle() >>ContextAPItests.test_pickle() >> > > Yes, this seems to have done the trick. Thanks for the suggestion. It may be worth offering a context manager/decorator equivalent to "import_fresh_module". > I'm still curious about the test-in-clean-env question though. As Stefan noted, the main advantage we get is that sometimes the failure to clean up properly is in the standard lib code rather than the tests, and with complete isolation we'd be less likely to notice the problem. Once you combine that with the fact that rearchitecting regrtest to work that way would be quite a bit of work, the motivation to make it happen goes way down. However, specifically spinning out the "import the world" tests like test_pydoc and test___all__ to a separate process might be worth the effort. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan wrote: > On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky wrote: > > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote: > >> > >> Eli Bendersky wrote: > >> > Yes, this is the solution currently used in test_xml_etree. However, > >> > once > >> > pickling tests are added things stop working. Pickle uses __import__ to > >> > import > >> > the module a class belongs to, bypassing all such trickery. So if > >> > test___all__ > >> > got _elementtree into sys.modules, pickle's __import__ finds it even if > >> > all the > >> > tests in test_xml_etree manage to ignore it for the Python version > >> > because they > >> > use import_fresh_module. > >> > >> I ran into the same problem for test_decimal. The only thing that appears > >> to work is to set sys.modules['decimal'] explicitly before calling > >> dumps()/loads(). See: > >> > >>PythonAPItests.test_pickle() > >>ContextAPItests.test_pickle() > > > > Yes, this seems to have done the trick. Thanks for the suggestion. > > It may be worth offering a context manager/decorator equivalent to > "import_fresh_module". I suggested making import_fresh_module a context manager in the issue that Eli opened about test___all__. > > I'm still curious about the test-in-clean-env question though. > > As Stefan noted, the main advantage we get is that sometimes the > failure to clean up properly is in the standard lib code rather than > the tests, and with complete isolation we'd be less likely to notice > the problem. > > Once you combine that with the fact that rearchitecting regrtest to > work that way would be quite a bit of work, the motivation to make it > happen goes way down. > > However, specifically spinning out the "import the world" tests like > test_pydoc and test___all__ to a separate process might be worth the > effort. Adding something to regertest (or unittest?) so that certain nominated test modules are run in a subprocess has been discussed previously, but so far no one has stepped up to implement it :) (I think this came up originally for test_site, but I don't remember for sure.) --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP for time zone support.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/30/2012 05:19 AM, Steven D'Aprano wrote: > There is no "Etc/GMT+11" named here: > > http://en.wikipedia.org/wiki/List_of_tz_database_time_zones > > nor is it included in /usr/share/zoneinfo/zone.tab in either of the > systems I looked at (one Debian, one Centos), but there is Etc/GMT. So > I conclude that the PEP allows timezone rules, not just names. FWIW, my Ubuntu box has zone data for 'ETC/GMT+11': $ file /usr/share/zoneinfo/posix/Etc/GMT+11 /usr/share/zoneinfo/posix/Etc/GMT+11: timezone data, version 2, \ 1 gmt time flag, 1 std time flag, no leap seconds, no transition times, \ 1 abbreviation char Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDgbjkACgkQ+gerLs4ltQ6w2QCgzqAFfOAigwVZMZEh+il+0grb jsYAoMm1g8xnXe1dcgkFMEX0n14grDSH =rCdb -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
Richard Oudkerk wrote: Personally I would like to get rid of the "purge globals" behaviour for modules deleted before shutdown has started: if someone manipulates sys.modules then they can just call gc.collect() if they want to promptly get rid of orphaned reference cycles. Now that we have cyclic gc, is there any need for the shutdown purge at all? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHONPATH processing change from 2.6 to 2.7 and Mac bundle builder problems
Issue filed as http://bugs.python.org/issue16821 I now have a fix that I can use, a trivia patch to the bundlebuilder.py from 2.6 gives me working code. The bundelbuilder in 2.7 is not in good shape, the code changes from the 2.6 version have bugs in them, at least one is a show stopper. I'd have to assume that the code was not tested. I'd suggest that you revert to the 2.6 version and apply the patch in the bug report so that this can make it into a 2.7.4 if you do another 2.7 release. I also noticed that it says that bundelbuilder will not be in python 3. Do you expect this functionality to be maintained outside of the core python code? Barry On 28 Dec 2012, at 23:57, Ned Deily wrote: > In article <9e6e3321-b0e7-4e77-afcb-9c7855649...@barrys-emacs.org>, > Barry Scott wrote: >> You did not set PYTHONHOME that effects the code in calculate_path a lot. >> Also there is platform specific code in tht code. >> On 28 Dec 2012, at 22:30, Antoine Pitrou wrote: >>> On Fri, 28 Dec 2012 21:39:56 + >>> Barry Scott wrote: I'm trying to track down why bundlebuilder no longer works with python 2.7 to create runnable Mac OS X apps. I have got as far as seeing that imports of modules are failing. What I see is that sys.path does not contain all the elements from the PYTHONPATH variable. No matter what I put in PYTHONPATH only the first element is in sys.path. >>> >>> I can't reproduce under Linux: >>> >>> $ PYTHONPATH=/x:/y python -Sc "import sys; print(sys.path)" >>> ['', '/x', '/y', '/usr/lib/python27.zip', '/usr/lib64/python2.7/', >>> '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', >>> '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload'] > > Barry, > > I think this discussion should be taking place on the bug tracker > (http://bugs.python.org), rather than in python-dev. bundlebuilder is > unique to OS X and fairly esoteric. Please open an issue there and > include a sample of how you created an app with bundlebuilder and what > Python 2.7 version you are using and what version of OS X. > > Thanks! > > -- > Ned Deily, > n...@acm.org > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/barry%40barrys-emacs.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test___all__ polluting sys.modules?
On Mon, 31 Dec 2012 10:25:25 +1300 Greg Ewing wrote: > Richard Oudkerk wrote: > > Personally I would like to get rid of the "purge globals" behaviour for > > modules deleted before shutdown has started: if someone manipulates > > sys.modules then they can just call gc.collect() if they want to > > promptly get rid of orphaned reference cycles. > > Now that we have cyclic gc, is there any need for the > shutdown purge at all? If you have an object with a __del__ method as a module global, the cyclic gc will refuse to consider the module globals at all (which means it will affect unrelated objects). So, yes, I think the shutdown purge is still necessary. Perhaps there are ways to make it smarter. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 431 Time zone support improvements - Update
On 30/12/12 07:16, Lennart Regebro wrote: If no database is found an ``UnknownTimeZoneError`` or subclass thereof will be raised with a message explaining that no zoneinfo database can be found, but that you can install one with the ``tzdata-update`` package. Why should we care about that situation if we *do* provide a database? Distributions can decide to exclude some files from their packages, but it's their problem, not ours. Yes, but a comprehensible error message is useful even if somebody messed up the system/configuration. +1 -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BDFL delegate for Daniel Holth's packaging PEPs?
Does anyone object to my naming myself as BDFL-Delegate for Daniel Holth's packaging PEPs? PEP 425 Compatibility Tags for Built Distributions PEP 426 Metadata for Python Software Packages 1.3 PEP 427 The Wheel Binary Package Format 0.1 I've mentioned doing so before, but IIRC it was in the depths of a larger thread, so I figured I should make a separate post before claiming them in the PEPs repo. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
