Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, 3 Feb 2013 16:44:33 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Sun, Feb 3, 2013 at 4:37 PM, Guido van Rossum gu...@python.org wrote: I don't know or care much about PyPI metadata, so do what you feel is right. If you are uncomfortable being PEP-uncle *and* -author, find another author or another uncle. But since it doesn't affect the language or library, it's fine with me if you are both. :-) To clarify what will happen if I handle both jobs: I'll bug a few specific people like Vinay Sajip (distlib), and MvL or Richard Jones (PyPI) to at least glance over it, as well as giving distutils-sig, catalog-sig and python-dev one last chance to comment on my revised draft. Then, wearing my BDFL-Delegate hat, I'd decide what feedback I considered worth addressing and what could be safely ignored (or postponed to the next time the metadata gets updated). I don't expect anything I want to do to be particularly controversial, but I think it's worth trying to get it right (even if it delays wheel support in pip for a few more weeks). Will wheel be implemented in distutils? 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On 3 February 2013 11:27, Antoine Pitrou solip...@pitrou.net wrote: I don't expect anything I want to do to be particularly controversial, but I think it's worth trying to get it right (even if it delays wheel support in pip for a few more weeks). Will wheel be implemented in distutils? There are no plans to do so (and I don't think it's necessary, particularly given the general distutils is frozen principle). To clarify: - The wheel project provides a bdist_wheel command to build wheels, but this depends on setuptools/distribute. I don't know how hard it would be to write a version that didn't depend on them. - The wheel project provides standalone commands to install wheels, and to convert eggs and wininst installers to wheels. The pip integration is basically to allow pip to find wheels on PyPI or any local indexes you have, and to install them via the pip install command. It also incidentally includes pip support for the new dist-info metadata format (I can't recall which PEP that is, sorry) simply because that's the format that wheel uses rather than the legacy egg-info format. So it's perfectly possible to use wheels right now, without the pip integration. But the pip developers don't want to integrate the wheel format just because it exists - they want the assurance that it's an accepted format supported by PEPs, hence the interest in getting the 3 wheel PEPs (of which the metadata PEP is the first) accepted. Paul ___ 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] 2.7.4
There are crashers for which patches were proposed but do not reviewed yet: Issue #6083: Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords. Issue #7358: cStringIO not 64-bit safe. Issue #16137: Using time.asctime() with an array with negative tm_hour causes Python Crash. Issue #16686: audioop overflow issues. #8865 is reviewed but not committed. ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, 3 Feb 2013 12:34:36 + Paul Moore p.f.mo...@gmail.com wrote: So it's perfectly possible to use wheels right now, without the pip integration. But the pip developers don't want to integrate the wheel format just because it exists - they want the assurance that it's an accepted format supported by PEPs, hence the interest in getting the 3 wheel PEPs (of which the metadata PEP is the first) accepted. But it's an accepted format by whom? If we accept the PEP but refuse to integrate support in the stdlib, it doesn't make much sense. I vote for removing the distutils is frozen principle. It was already destructive enough when packaging was still alive - bug fixes were actively turned down for the dubious reason that fixing bugs would break compatibility. Its rationale has become completely obsolete now that packaging has failed. 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, Feb 3, 2013 at 10:34 PM, Paul Moore p.f.mo...@gmail.com wrote: So it's perfectly possible to use wheels right now, without the pip integration. But the pip developers don't want to integrate the wheel format just because it exists - they want the assurance that it's an accepted format supported by PEPs, hence the interest in getting the 3 wheel PEPs (of which the metadata PEP is the first) accepted. And they're right to be concerned - I've just made it clear to Daniel that before PEP 427 will be accepted, it must either switch to using S/MIME for signatures and drop support for Java Web Signatures completely, or else it must contain a compelling rationale for why we should even be considering a signature scheme that isn't yet an IETF standard. I take the disclaimer the IETF put on their drafts seriously: It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. MvL raised this concern last time the wheel format was discussed, and, to date, nothing has happened to address it. JWS *does* look like a neat piece of technology, but it's just too young to be basing our binary distribution infrastructure on it (especially as new crypto is, by default, bad crypto - that's why NIST/NSA hold their multi-year competitions when they need to come up with new crypto related algorithms). The other two PEPs (the new metadata and the version compatibility tags) are in a much better place. Most of the issues with PEP 426 have been inherited from the previous version of the metadata, rather than being related to the changes Daniel needed for the wheel format, and I've just completed a new draft that should address most of those problems. It's been a while since I looked closely at the compatibility tag PEP, but I don't recall their being any significant problems with it last time it was discussed. 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, Feb 3, 2013 at 10:48 PM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 3 Feb 2013 12:34:36 + Paul Moore p.f.mo...@gmail.com wrote: So it's perfectly possible to use wheels right now, without the pip integration. But the pip developers don't want to integrate the wheel format just because it exists - they want the assurance that it's an accepted format supported by PEPs, hence the interest in getting the 3 wheel PEPs (of which the metadata PEP is the first) accepted. But it's an accepted format by whom? If we accept the PEP but refuse to integrate support in the stdlib, it doesn't make much sense. I vote for removing the distutils is frozen principle. It was already destructive enough when packaging was still alive - bug fixes were actively turned down for the dubious reason that fixing bugs would break compatibility. Its rationale has become completely obsolete now that packaging has failed. The rationale for the distutils freeze is don't break setuptools. That rationale still holds. The most likely current candidate for integration into Python 3.4 is distlib, which, as was proposed when packaging was dropped, is built incrementally as components are standardised, rather than being a mish-mash of updated code and flawed design inherited from distutils. Regards, 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, 3 Feb 2013 23:08:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Sun, Feb 3, 2013 at 10:48 PM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 3 Feb 2013 12:34:36 + Paul Moore p.f.mo...@gmail.com wrote: So it's perfectly possible to use wheels right now, without the pip integration. But the pip developers don't want to integrate the wheel format just because it exists - they want the assurance that it's an accepted format supported by PEPs, hence the interest in getting the 3 wheel PEPs (of which the metadata PEP is the first) accepted. But it's an accepted format by whom? If we accept the PEP but refuse to integrate support in the stdlib, it doesn't make much sense. I vote for removing the distutils is frozen principle. It was already destructive enough when packaging was still alive - bug fixes were actively turned down for the dubious reason that fixing bugs would break compatibility. Its rationale has become completely obsolete now that packaging has failed. The rationale for the distutils freeze is don't break setuptools. That rationale still holds. I'm sure it is perfectly possible to evolve and bugfix distutils without breaking distribute. What's more, distribute is actually maintained and can evolve to accomodate the fixes. As for setuptools (as opposed to distribute), I don't think we should care anymore. 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, Feb 3, 2013 at 11:04 PM, Nick Coghlan ncogh...@gmail.com wrote: MvL raised this concern last time the wheel format was discussed, and, to date, nothing has happened to address it. My apologies to Daniel, it appears I misremembered this part of the previous discussion. Daniel assures me MvL was objecting primarily to the use of one particular crypto algorithm (which was subsequently removed from the PEP), rather than the use of JWS in general. That said, my own concerns about relying on an Internet Draft (when the IETF specifically say not to do that) remain. It just means they're a new issue, rather than one continuing over from the previous discussion. 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/2013 08:09 AM, Antoine Pitrou wrote: I'm sure it is perfectly possible to evolve and bugfix distutils without breaking distribute. What's more, distribute is actually maintained and can evolve to accomodate the fixes. I wouldn't be on that proposition: there are a lot of burnouts down that rabbit hole. As for setuptools (as opposed to distribute), I don't think we should care anymore. Yes, you need to care. It is *still* true today that distribute and setuptools remain largely interchangeable, which is the only thing that makes distribute viable, in the ecosystem sense. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEOZakACgkQ+gerLs4ltQ5N7ACgv/v0GTs7xyQ7I/jvrcu/s2i5 kHcAoJUKigWKZTiVr1ARMLt2xtQF+TAL =mjAm -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] [Python-checkins] cpython (3.3): Issue #17098: Be more stringent of setting __loader__ on early imported
FYI, Raymond let me know that this is causing the buildbots to occasionally
fail thanks to xml.parsers.expat.errors somehow circumventing import. I'm
going to try and figure out what's going on.
On Fri, Feb 1, 2013 at 4:38 PM, brett.cannon python-check...@python.orgwrote:
http://hg.python.org/cpython/rev/19ea454ccdf7
changeset: 81884:19ea454ccdf7
branch: 3.3
parent: 81882:4a4688b865ff
user:Brett Cannon br...@python.org
date:Fri Feb 01 15:31:49 2013 -0500
summary:
Issue #17098: Be more stringent of setting __loader__ on early imported
modules. Also made test more rigorous.
files:
Lib/importlib/_bootstrap.py |7 +-
Lib/test/test_importlib/test_api.py |6 +
Python/importlib.h | 591 ---
3 files changed, 310 insertions(+), 294 deletions(-)
diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
--- a/Lib/importlib/_bootstrap.py
+++ b/Lib/importlib/_bootstrap.py
@@ -1704,10 +1704,13 @@
BYTECODE_SUFFIXES = DEBUG_BYTECODE_SUFFIXES
module_type = type(sys)
-for module in sys.modules.values():
+for name, module in sys.modules.items():
if isinstance(module, module_type):
if not hasattr(module, '__loader__'):
-module.__loader__ = BuiltinImporter
+if name in sys.builtin_module_names:
+module.__loader__ = BuiltinImporter
+elif _imp.is_frozen(name):
+module.__loader__ = FrozenImporter
self_module = sys.modules[__name__]
for builtin_name in ('_io', '_warnings', 'builtins', 'marshal'):
diff --git a/Lib/test/test_importlib/test_api.py
b/Lib/test/test_importlib/test_api.py
--- a/Lib/test/test_importlib/test_api.py
+++ b/Lib/test/test_importlib/test_api.py
@@ -184,6 +184,12 @@
if isinstance(module, types.ModuleType):
self.assertTrue(hasattr(module, '__loader__'),
'{!r} lacks a __loader__ attribute'.format(name))
+if name in sys.builtin_module_names:
+self.assertEqual(importlib.machinery.BuiltinImporter,
+ module.__loader__)
+elif imp.is_frozen(name):
+self.assertEqual(importlib.machinery.FrozenImporter,
+ module.__loader__)
def test_main():
from test.support import run_unittest
diff --git a/Python/importlib.h b/Python/importlib.h
--- a/Python/importlib.h
+++ b/Python/importlib.h
[stripped]
--
Repository URL: http://hg.python.org/cpython
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
___
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] 2.7.4
2013/2/3 Serhiy Storchaka storch...@gmail.com: There are crashers for which patches were proposed but do not reviewed yet: Issue #6083: Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords. Issue #7358: cStringIO not 64-bit safe. Issue #16137: Using time.asctime() with an array with negative tm_hour causes Python Crash. Issue #16686: audioop overflow issues. #8865 is reviewed but not committed. Thanks. In the future, this should be raised to release blocker priority to get my attention. -- Regards, Benjamin ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
The neat thing about wheel is that you can install them without having the software used to build them. So we might try to provide a very simple wheel installer script with Python that did not even depend on DistUtils. You would be able to install pip etc with that tool. There is no need to put wheel directly into DistUtils. On Feb 3, 2013 7:54 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 3 Feb 2013 12:34:36 + Paul Moore p.f.mo...@gmail.com wrote: So it's perfectly possible to use wheels right now, without the pip integration. But the pip developers don't want to integrate the wheel format just because it exists - they want the assurance that it's an accepted format supported by PEPs, hence the interest in getting the 3 wheel PEPs (of which the metadata PEP is the first) accepted. But it's an accepted format by whom? If we accept the PEP but refuse to integrate support in the stdlib, it doesn't make much sense. I vote for removing the distutils is frozen principle. It was already destructive enough when packaging was still alive - bug fixes were actively turned down for the dubious reason that fixing bugs would break compatibility. Its rationale has become completely obsolete now that packaging has failed. 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/dholth%40gmail.com ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, 3 Feb 2013 09:41:29 -0500 Daniel Holth dho...@gmail.com wrote: The neat thing about wheel is that you can install them without having the software used to build them. So we might try to provide a very simple wheel installer script with Python that did not even depend on DistUtils. You would be able to install pip etc with that tool. There is no need to put wheel directly into DistUtils. But you still need to *produce* wheels, don't you? It would be more useful for everyone if that facility was bundled with Python. 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On 3 February 2013 14:41, Daniel Holth dho...@gmail.com wrote: The neat thing about wheel is that you can install them without having the software used to build them. So we might try to provide a very simple wheel installer script with Python that did not even depend on DistUtils. You would be able to install pip etc with that tool. There is no need to put wheel directly into DistUtils. The other side of the equation, adding a bdist_wheel command to distutils should *also* be simple. As command classes are essentially independent code, it's not even really going to violate whatever remains of the distutils is frozen philosophy. Is there any mileage to submitting a patch to the Python stdlib that implements a bdist_wheel distutils subcommand and a wheel installer in the stdlib? I'm willing to write that patch based on Daniel's existing wheel code if no-one else is willing to, but only if there's likely to be some level of support from python-dev (for example, if Antoine and Nick are in general agreement on the principle, I'd be willing to write the code and we could see where the subsequent debate leads). Paul ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On 4 Feb 2013 00:54, Paul Moore p.f.mo...@gmail.com wrote: On 3 February 2013 14:41, Daniel Holth dho...@gmail.com wrote: The neat thing about wheel is that you can install them without having the software used to build them. So we might try to provide a very simple wheel installer script with Python that did not even depend on DistUtils. You would be able to install pip etc with that tool. There is no need to put wheel directly into DistUtils. The other side of the equation, adding a bdist_wheel command to distutils should *also* be simple. As command classes are essentially independent code, it's not even really going to violate whatever remains of the distutils is frozen philosophy. Is there any mileage to submitting a patch to the Python stdlib that implements a bdist_wheel distutils subcommand and a wheel installer in the stdlib? I'm willing to write that patch based on Daniel's existing wheel code if no-one else is willing to, but only if there's likely to be some level of support from python-dev (for example, if Antoine and Nick are in general agreement on the principle, I'd be willing to write the code and we could see where the subsequent debate leads). Adding a bdist_wheel command makes sense to me, and I agree it is the kind of change that shouldn't cause setuptools any grief. The original trigger for the distutils freeze was a ban on internal refactoring, so new features that don't alter internal APIs should be fine. My one real concern at this point is the signature scheme. We definitely need one, so dropping it from the PEP isn't an option, but the choice of JWS over S/MIME worries me. The two acceptable options I currently see are to wait until JWS is approved by the IETF, or wait until an S/MIME based wheel implementation is available. I'd love to be able to just accept the wheel format as it stands, but absent a compelling pro-JWS story in the PEP, it isn't going to happen :( I'd also hold off on a wheel downloader for now, that side of things is likely to be affected if/when distlib gets proposed for 3.4. Paul ___ 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/ncoghlan%40gmail.com ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Feb 03, 2013, at 04:04 PM, Nick Coghlan wrote: - someone else volunteers to be BDFL-Delegate for PEP 426 (MvL, perhaps?) On principle, I think it's a good idea to try to recruit another PEP czar. I'm not volunteering though, due to lack of time. Cheers, -Barry ___ 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] BDFL delegation for PEP 426 + distutils freeze
Hi, I don’t have a problem with Nick improving the PEP and deciding on its acceptance. Le 03/02/2013 07:48, Antoine Pitrou a écrit : On Sun, 3 Feb 2013 12:34:36 + Paul Moore p.f.mo...@gmail.com wrote: So it's perfectly possible to use wheels right now, without the pip integration. But the pip developers don't want to integrate the wheel format just because it exists - they want the assurance that it's an accepted format supported by PEPs, hence the interest in getting the 3 wheel PEPs (of which the metadata PEP is the first) accepted. But it's an accepted format by whom? If we accept the PEP but refuse to integrate support in the stdlib, it doesn't make much sense. There’s a chicken and egg problem: python-dev could have waited a year or two to see the wheel format being used and fixed/improved before deciding to do something in the stdlib, but the pip maintainers wanted an official blessing first. Accepting the wheel PEP would mean that python-dev and the community think wheels are an interesting way forward, and after some time needed to find out what fixes and improvements are needed, python-dev is ready to add stable, official support in the stdlib. (I know Daniel Holth is frustrated by the wait for what he sees as a simple format that’s been stable since last year, but it’s really not long for stdlib inclusion, and there *are* things to sort out.) I vote for removing the distutils is frozen principle. I’ve also been thinking about that. There have been two exceptions to the freeze, for ABI flags in extension module names and for pycache directories. When the stable ABI was added and MvL wanted to change distutils (I don’t know to do what exactly), Tarek stood firm on the freeze and asked for any improvement to go into distutils2, and after MvL said that he would not contibute to an outside project, we merged d2 into the stdlib. Namespace packages did not impact distutils either. Now that we’ve removed packaging from the stdlib, we have two Python features that are not supported in the standard packaging system, and I agree that it is a bad thing for our users. I’d like to propose a reformulation of the freeze: - refactorings for the sake of cleanup are still shunned - fixes to really old bugs that have become the expected behavior are still avoided - fixes to follow OS changes are still allowed (we’ve had a number for Debian multiarch, Apple moving stuff around, Windows manifest options changes) - support for Python evolutions that involve totally new code, commands or setup parameters are now possible (this enables stable API support as well as a new bdist format) - behavior changes to track Python behavior changes are now possible (this enables recognizing namespace packages, unless we decide they need a new setup parameter) We’ll probably need to talk this over at PyCon (FYI I won’t be at the language summit but I’ll take part in the packaging mini-summit planned thanks to Nick). Regards ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
My position is that these days distutils doesn't belong in the standard library any more than Django does. So I am mildly opposed to supporting it when you should be using better designed third party tools like Bento or setuptools. Wheel makes it possible for Python to get out of the build tool business. Just install your preferred tools with a concise bootstrap installer. On Sun, 3 Feb 2013 09:41:29 -0500 Daniel Holth dho...@gmail.com wrote: The neat thing about wheel is that you can install them without having the software used to build them. So we might try to provide a very simple wheel installer script with Python that did not even depend on DistUtils. You would be able to install pip etc with that tool. There is no need to put wheel directly into DistUtils. But you still need to *produce* wheels, don't you? It would be more useful for everyone if that facility was bundled with Python. 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/dholth%40gmail.com ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
Hi, Le 03/02/2013 13:57, Daniel Holth a écrit : My position is that these days distutils doesn't belong in the standard library any more than Django does. You can install anything you want, but first you need an installer. I think that a language needs packaging formats and basic build and install tools in its stdlib. You can use different tools for specialized needs or tastes, but I think years and years of frustration show that people need a basic thing working out of the box. So I am mildly opposed to supporting it when you should be using better designed third party tools like Bento Aside: can we keep the discussion civil instead of constantly bashing distutils and heaping praise on one tool? (It happened with easy_install before bento.) I’m the first one to recognize that distutils has deep flaws, but I respect the time and energy that many people have put into it. Wheel makes it possible for Python to get out of the build tool business. Just install your preferred tools with a concise bootstrap installer. Looks like we agree that a basic tool able to bootstrap the packaging story is needed :) Regards ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
Daniel Holth dho...@gmail.com writes: Wheel makes it possible for Python to get out of the build tool business. Just install your preferred tools with a concise bootstrap installer. If this is true, it would also have been possible with eggs, yet it didn't happen. Why do you think it will happen now or am I missing something? ___ 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] BDFL delegation for PEP 426 + distutils freeze
On Sun, Feb 3, 2013 at 10:33 AM, Éric Araujo mer...@netwok.org wrote: Le 03/02/2013 07:48, Antoine Pitrou a écrit : I vote for removing the distutils is frozen principle. I’ve also been thinking about that. There have been two exceptions to the freeze, for ABI flags in extension module names and for pycache directories. When the stable ABI was added and MvL wanted to change distutils (I don’t know to do what exactly), Tarek stood firm on the freeze and asked for any improvement to go into distutils2, and after MvL said that he would not contibute to an outside project, we merged d2 into the stdlib. Namespace packages did not impact distutils either. Now that we’ve removed packaging from the stdlib, we have two Python features that are not supported in the standard packaging system, and I agree that it is a bad thing for our users. I’d like to propose a reformulation of the freeze: This could be common knowledge, but is the current formulation of the freeze spelled out somewhere? --Chris ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
Bento is the only available packaging tool to heap praise onto and it is impressive. I am reacting to all the hate heaped on setup tools when I think the underlying DistUtils design is a big part of the problem. My feeling is that stdlib packaging tools should be for bootstrapping and reference, more like wsgiref than django. Wheel is very similar to egg but tries to solve the original setup tools sin of installing something you don't want (the entire setuptools build system) by omitting the runtime component. The result is a very reviewable couple hundred lines bootstrap installer or unzip in a pinch. Its also built upon Python standards that were not available when easy_install was introduced. On Feb 3, 2013 2:09 PM, Ralf Schmitt r...@systemexit.de wrote: Daniel Holth dho...@gmail.com writes: Wheel makes it possible for Python to get out of the build tool business. Just install your preferred tools with a concise bootstrap installer. If this is true, it would also have been possible with eggs, yet it didn't happen. Why do you think it will happen now or am I missing something? ___ 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/dholth%40gmail.com ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, Feb 3, 2013 at 9:42 PM, Daniel Holth dho...@gmail.com wrote: Bento is the only available packaging tool to heap praise onto and it is impressive. If Bento is cool, is there some way we can help it gain more traction in the Python ecosystem? Not necessarily by incorporating it into stdlib, but perhaps by officially sanctioning it in other ways (documentation, PyPI, perhaps getting some helpful hooks / tweaks to Python itself)? I don't know the answer to these questions, but if there is a good solution out there, it would be cool to throw our community weight behind it. Schiavo Simon ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, Feb 3, 2013 at 2:00 PM, Simon Cross hodgestar+python...@gmail.com wrote: On Sun, Feb 3, 2013 at 9:42 PM, Daniel Holth dho...@gmail.com wrote: Bento is the only available packaging tool to heap praise onto and it is impressive. If Bento is cool, is there some way we can help it gain more traction in the Python ecosystem? Not necessarily by incorporating it into stdlib, but perhaps by officially sanctioning it in other ways (documentation, PyPI, perhaps getting some helpful hooks / tweaks to Python itself)? I don't know the answer to these questions, but if there is a good solution out there, it would be cool to throw our community weight behind it. I don't think we, as in python-dev, should do this. If people want to start telling others to use bento on their own, that's fine. For the core team to get behind it would probably require a lot of work to safely stamp it as the new way...that we don't actually have anything to do with If python-dev officially says hey, use bento, then it has all sorts of problems and ends up dying in 6 months, we will look like idiots. ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
The pip integration is basically to allow pip to find wheels on PyPI or any local indexes you have, and to install them via the pip install command. it also offers pip wheel for building wheels (using bdist_wheel) locally for your requirements, since wheels wouldn't be pervasive on PyPI for a while so, let's say you have a large app that has a requirements file, that ultimately installs 90 packages. run: pip wheel --wheel-dir=/my_wheels -r requirements.txt this will produce 90 wheel archives in a local directory, that you can then install against. Marcus ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, Feb 3, 2013 at 8:08 AM, Nick Coghlan ncogh...@gmail.com wrote: The rationale for the distutils freeze is don't break setuptools. That rationale still holds. IIRC, the historical issue that triggered the freeze was not that the distutils refactoring broke setuptools, but that it did so in what was supposed to be a bugfix-only release of Python, via a change to what appeared to be a public/documented method. This rationale doesn't apply to major/minor releases of Python, and the freeze was only supposed to apply to 2.x in any event. (IIRC, some of the breakage was the result of backporting 3.x distutils changes to 2.x.) Anyway, adding features or refactoring distutils is not the problem: doing it in bugfix releases is. With normal releases, third-party extenders of distutils at least have the opportunity to test and issue updates in a timely fashion. ___ 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] Interested in GSoC 2013
Hi, I'm Jainit and I'm planning to apply for GSoC 2013 for the PSF. I was also part of GSoC 2012 in interface ecology lab, Texas AM university. I just gone though Python developer's guide and how to become core contributor document. And I just compiled CPython on my machine. Since I'm new to this community, Can anyone assign me some task/issues/bug to work on to get the better idea of how things works. I would also like to know if any of you have any ideas which can be implemented this summer. Thanks!, Jainit ___ 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] BDFL delegation for PEP 426 + distutils freeze
I did think that updating distutils to have basic support for the packaging
PEPs was a decent idea, but then it wound up being more or less rewritten
entirely like I've been cajoled into doing with PEP 426 (Metadata). I don't
know whether distutils(1) can survive the minimum changes required for
wheel (.dist-info folders and a bdist_wheel command) without breaking a
significant number of its clients or not. History suggests no. It may still
be worth a shot.
bdist_wheel started out as a distutils2 plugin but it was inconvenient to
develop it inside the CPython repository and it was not practical to
convert projects over from setuptools to distutils2.
The pypi metadata has had a standardlib generator for a long time without
having anything in the standard library to make use of the metadata. Wheels
are just .zip files of one package's share of the site-packages directory.
Why not support them asymmetrically. I value the PEP and consensus for the
format more than the implementation.
One idea that's sure to be controversial would be to include a bootstrap
installer as a script without committing to a Python API (just a
command-line API). Since Python 2.6, wheel's own wheel archive can be used
to install wheels:
$ python wheel-0.14.0-py2.py3-none-any.whl/wheel -h
usage: wheel [-h] {keygen,sign,verify,unpack,install,convert,help} ...
On Sun, Feb 3, 2013 at 2:40 PM, Chris Jerdonek chris.jerdo...@gmail.comwrote:
On Sun, Feb 3, 2013 at 10:33 AM, Éric Araujo mer...@netwok.org wrote:
Le 03/02/2013 07:48, Antoine Pitrou a écrit :
I vote for removing the distutils is frozen principle.
I’ve also been thinking about that. There have been two exceptions to
the freeze, for ABI flags in extension module names and for pycache
directories. When the stable ABI was added and MvL wanted to change
distutils (I don’t know to do what exactly), Tarek stood firm on the
freeze and asked for any improvement to go into distutils2, and after
MvL said that he would not contibute to an outside project, we merged d2
into the stdlib. Namespace packages did not impact distutils either.
Now that we’ve removed packaging from the stdlib, we have two Python
features that are not supported in the standard packaging system, and I
agree that it is a bad thing for our users.
I’d like to propose a reformulation of the freeze:
This could be common knowledge, but is the current formulation of the
freeze spelled out somewhere?
--Chris
___
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/dholth%40gmail.com
___
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] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build
On Thu, Jan 31, 2013 at 11:14 PM, Antoine Pitrou solip...@pitrou.netwrote: On Fri, 1 Feb 2013 11:00:24 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 1, 2013 at 9:50 AM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 31 Jan 2013 23:52:27 +0100 (CET) matthias.klose python-check...@python.org wrote: http://hg.python.org/cpython/rev/8ee6d96a1019 changeset: 81859:8ee6d96a1019 branch: 2.7 parent: 81855:df9f8feb7444 user:d...@python.org date:Thu Jan 31 23:52:03 2013 +0100 summary: - Issue #17086: Backport the patches from the 3.3 branch to cross-build the package. You aren't supposed to add new features to bugfix branches. Did you have a specific reason to do this? One of the reasons for the long maintenance period on 2.7 is to keep it building as the underlying platforms change. With the rise of ARM systems, being able to reliably cross-build Python 2.7 for ARM from an x86_64 system is fairly important. I would like to see a better argument for this. The rise of ARM systems is the rise of ARM systems powerful enough to build Python without cross-compiling (which is why we *now* have ARM buildbots). The very small ARM systems which need cross-compiling have existed for decades. It is quite common for developers to build a single code base on a single workstation targeting a plethora of platforms all at once. Requiring native systems with self hosting tool-chains for builds is a non-starter as those often don't exist. Making Python 2.7's configure+makefiles easier to cross compile out of the box is a good thing. Side note: we really need a cross compiling build-bot host + target system or we'll inevitably break this. That said, as a procedural point for build related new features in 2.7, I agree they should be proposed, with an explicit rationale, on python-dev before proceeding with the commit. I think this huge changeset should be reverted. It's a complete failure in terms of procedure and following the rules. Just because it can be useful is not a good enough reason to violate our release model without even asking. That's up to the 2.7 release manager. Yes, this could have been done better by asking first. But IMNSHO I'd prefer to see it stay in. -gps 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/greg%40krypto.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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
Paul Moore p.f.moore at gmail.com writes: So it's perfectly possible to use wheels right now, without the pip integration. But the pip developers don't want to integrate the wheel format just because it exists - they want the assurance that it's an accepted format supported by PEPs, hence the interest in getting the 3 wheel PEPs (of which the metadata PEP is the first) accepted. Likewise, I will look at the possibility of providing wheel support in distlib, once it has been accepted as a standard and the open issues (such as signature scheme) have been resolved. Regards, Vinay Sajip ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
They can be signed with pypi detached signatures already. It works now exactly as for sdist. The innovation was supposed to be in convenience for the signer, in allowing keys to be trusted per package and for a list of dependencies and the expected signing keys to be shared easily. Does anyone have a concise pure py3 s/mime implementation? On Feb 3, 2013 4:52 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Paul Moore p.f.moore at gmail.com writes: So it's perfectly possible to use wheels right now, without the pip integration. But the pip developers don't want to integrate the wheel format just because it exists - they want the assurance that it's an accepted format supported by PEPs, hence the interest in getting the 3 wheel PEPs (of which the metadata PEP is the first) accepted. Likewise, I will look at the possibility of providing wheel support in distlib, once it has been accepted as a standard and the open issues (such as signature scheme) have been resolved. Regards, Vinay Sajip ___ 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/dholth%40gmail.com ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
Daniel Holth dholth at gmail.com writes: Bento is the only available packaging tool to heap praise onto and it is impressive. I am reacting to all the hate heaped on setup tools when I think the underlying DistUtils design is a big part of the problem. My feeling is that stdlib packaging tools should be for bootstrapping and reference, more like wsgiref than django. Bento is interesting, but I wouldn't jump to heap praise onto it. Apart from the somewhat idiosyncratic source style, David Cournapeau himself points to what he regards as weaknesses in it[1]. It is no doubt a better build tool than distutils for NumPy/SciPy users, and that's great. However, from what I could see, the documentation is not very detailed, making it hard to evaluate, and much of the build internals seem to be in some other tool called yaku, for which I couldn't find much documentation. When I see a sentiment suggesting that Python should get out of the build tools business (paraphrasing what Daniel said, not quoting him), I can certainly see why the distutils compiler infrastructure would make one think that, if it was impossible to come up with something better. However, I do feel there is room for a battery included in this area, as long as it is simple and easier to build on than distutils has been. Although I have not started to add anything in this area to distlib, I have spent some time thinking about the problems, and I have some experimental work in mind. I don't believe that hate is the right word when talking about why setuptools isn't loved more by python-dev. Since it was extending the flawed distutils design, it doesn't make sense to have it getting any closer to the stdlib, and it could perhaps be argued that distutils2/packaging also failed to make sufficient progress for the same reason. Certainly, with distlib I've tried to incorporate a lot of the setuptools functionality which developers find useful - in-package data, package exports (entry points), wrapping callables with scripts and so on. Regards, Vinay Sajip [1] http://bento.readthedocs.org/en/latest/faq.html#why-shouldn-t-i-use-bento ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Mon, Feb 4, 2013 at 12:16 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Bento is interesting, but I wouldn't jump to heap praise onto it. Apart from the somewhat idiosyncratic source style, David Cournapeau himself points to what he regards as weaknesses in it[1]. For the record, all the reasons listed at [1] appear trivial. [1] http://bento.readthedocs.org/en/latest/faq.html#why-shouldn-t-i-use-bento Schiavo Simon ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
Éric Araujo merwok at netwok.org writes: Looks like we agree that a basic tool able to bootstrap the packaging story is needed :) Agreed. Just because distutils can't easily/reliably build things that are better built with SCons/WAF/tup/whatever, doesn't mean that we shouldn't have the ability to build pure-Python distributions and distributions including C libs and extensions, with the ability to extend easily by third-party tools. It just needs to be done in a way which is easy to build on, so the included battery stays small and simple. Easier said than done, I know :-) Regards, Vinay Sajip ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
Simon Cross hodgestar+pythondev at gmail.com writes: For the record, all the reasons listed at [1] appear trivial. In Bento's author's own words - Weak documentation, Mediocre code quality, at a lower level, a lot of code leaves to be desired may be trivial if David is just being self-deprecating, but what if he isn't? Or perhaps that part of the page is out of date, and needs updating? I can certainly agree with the Weak documentation part of the assessment, but this makes it hard to assess the package as a whole. Note that I'm not sniping - writing good documentation is hard work. Regards, Vinay Sajip ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
He is being self deprecating. Its also true that python dev can't recommend bento wholesale. That is fine with me. On Feb 3, 2013 5:36 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Simon Cross hodgestar+pythondev at gmail.com writes: For the record, all the reasons listed at [1] appear trivial. In Bento's author's own words - Weak documentation, Mediocre code quality, at a lower level, a lot of code leaves to be desired may be trivial if David is just being self-deprecating, but what if he isn't? Or perhaps that part of the page is out of date, and needs updating? I can certainly agree with the Weak documentation part of the assessment, but this makes it hard to assess the package as a whole. Note that I'm not sniping - writing good documentation is hard work. Regards, Vinay Sajip ___ 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/dholth%40gmail.com ___ 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] 2.7.4
Just to clarify, the release branch hasn't been created yet, correct? - Nadeem On Sun, Feb 3, 2013 at 3:38 PM, Benjamin Peterson benja...@python.orgwrote: 2013/2/3 Serhiy Storchaka storch...@gmail.com: There are crashers for which patches were proposed but do not reviewed yet: Issue #6083: Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords. Issue #7358: cStringIO not 64-bit safe. Issue #16137: Using time.asctime() with an array with negative tm_hour causes Python Crash. Issue #16686: audioop overflow issues. #8865 is reviewed but not committed. Thanks. In the future, this should be raised to release blocker priority to get my attention. -- Regards, Benjamin ___ 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/nadeem.vawda%40gmail.com ___ 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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, Feb 3, 2013 at 10:34 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Simon Cross hodgestar+pythondev at gmail.com writes: For the record, all the reasons listed at [1] appear trivial. In Bento's author's own words - Weak documentation, Mediocre code quality, at a lower level, a lot of code leaves to be desired may be trivial if David is just being self-deprecating, but what if he isn't? Or perhaps that part of the page is out of date, and needs updating? I can certainly agree with the Weak documentation part of the assessment, but this makes it hard to assess the package as a whole. Note that I'm not sniping - writing good documentation is hard work. You are putting the words out of the context in which those were written: it is stated that the focus is on the general architecture and low-coupling which are the main issues I saw with distutils. Bento is designed to use multiple build backends (it can use distutils to build C extensions, or waf, the latter being how numpy/scipy is being built with bento). FWIW, I am not in favor of having bento blessed (or any other tool for that matter). The fundamental mistake of the previous attempts at packaging has been to formalize too early, or impose de-facto standards without much specification. That's why wheel and similar efforts are the way forward: they tackle a narrow but well defined sub-problem of packaging. Thus, they can be reused by other libraries to build higher abstractions. They are also less prone to the 'fatigue' that often arise in packaging efforts. 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] 2.7.4
On Sun, Feb 3, 2013 at 6:08 PM, Nadeem Vawda nadeem.va...@gmail.com wrote: Just to clarify, the release branch hasn't been created yet, correct? It's by tag and no: http://hg.python.org/cpython/tags -Brett - Nadeem On Sun, Feb 3, 2013 at 3:38 PM, Benjamin Peterson benja...@python.orgwrote: 2013/2/3 Serhiy Storchaka storch...@gmail.com: There are crashers for which patches were proposed but do not reviewed yet: Issue #6083: Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords. Issue #7358: cStringIO not 64-bit safe. Issue #16137: Using time.asctime() with an array with negative tm_hour causes Python Crash. Issue #16686: audioop overflow issues. #8865 is reviewed but not committed. Thanks. In the future, this should be raised to release blocker priority to get my attention. -- Regards, Benjamin ___ 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/nadeem.vawda%40gmail.com ___ 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/brett%40python.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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On 4 Feb 2013 09:22, David Cournapeau courn...@gmail.com wrote: On Sun, Feb 3, 2013 at 10:34 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Simon Cross hodgestar+pythondev at gmail.com writes: For the record, all the reasons listed at [1] appear trivial. In Bento's author's own words - Weak documentation, Mediocre code quality, at a lower level, a lot of code leaves to be desired may be trivial if David is just being self-deprecating, but what if he isn't? Or perhaps that part of the page is out of date, and needs updating? I can certainly agree with the Weak documentation part of the assessment, but this makes it hard to assess the package as a whole. Note that I'm not sniping - writing good documentation is hard work. You are putting the words out of the context in which those were written: it is stated that the focus is on the general architecture and low-coupling which are the main issues I saw with distutils. Bento is designed to use multiple build backends (it can use distutils to build C extensions, or waf, the latter being how numpy/scipy is being built with bento). FWIW, I am not in favor of having bento blessed (or any other tool for that matter). The fundamental mistake of the previous attempts at packaging has been to formalize too early, or impose de-facto standards without much specification. That's why wheel and similar efforts are the way forward: they tackle a narrow but well defined sub-problem of packaging. Thus, they can be reused by other libraries to build higher abstractions. They are also less prone to the 'fatigue' that often arise in packaging efforts. Another couple of key pieces are Setup-Requires-Dist and the extension mechanism in PEP 426 - they're intended to make it easier to communicate the use of third party tools for building, packaging and installation, as well as making it easier to provide additional metadata for the benefit of those tools. Cheers, Nick. 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/ncoghlan%40gmail.com ___ 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] update on 2.7.4
As you may have noticed, no 2.7.4 rc has been created yet. Yesterday, the buildbots were all red, and release blocker issues had to be dealt with. Today, I was not as availabIe and people were fixing important-looking crashers. In general, there seems to have been a lot more last-minute scrambling around than usual for a bugfix release. I'm afraid I'm still going to have to delay longer to see if we can get a few security patches in. It could be next week. Benjamin ___ 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] Interested in GSoC 2013
First, welcome to Python. For people just starting out contributing we have setup a core-mentorship mailing list ideally suited for this type of question. http://mail.python.org/mailman/listinfo/core-mentorship general tip: look for open issues marked with the 'easy' on bugs.python.org. On Sun, Feb 3, 2013 at 12:51 PM, Jainit Purohit mjai...@gmail.com wrote: Hi, I'm Jainit and I'm planning to apply for GSoC 2013 for the PSF. I was also part of GSoC 2012 in interface ecology lab, Texas AM university. I just gone though Python developer's guide and how to become core contributor document. And I just compiled CPython on my machine. Since I'm new to this community, Can anyone assign me some task/issues/bug to work on to get the better idea of how things works. I would also like to know if any of you have any ideas which can be implemented this summer. Thanks!, Jainit ___ 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/greg%40krypto.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] BDFL delegation for PEP 426 (PyPI metadata 1.3)
David Cournapeau cournape at gmail.com writes: You are putting the words out of the context in which those were written: it is stated that the focus is on the general architecture OK, no offence was meant. Thanks for the clarification. Regards, Vinay Sajip ___ 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] update on 2.7.4
On Sun, Feb 3, 2013 at 4:11 PM, Benjamin Peterson benja...@python.orgwrote: As you may have noticed, no 2.7.4 rc has been created yet. Yesterday, the buildbots were all red, and release blocker issues had to be dealt with. Today, I was not as availabIe and people were fixing important-looking crashers. In general, there seems to have been a lot more last-minute scrambling around than usual for a bugfix release. I'm afraid I'm still going to have to delay longer to see if we can get a few security patches in. It could be next week. Thanks for the update, Benjamin. Given the recent discussions and events, I would feel even safer if more than a week passed. I don't see how waiting a bit longer is going to hurt anyone. At this point in 2.7's life, stability is perhaps the most important thing. Perhaps this is the right time to specifically ask all contributors to consider what may be blocking such a release - any bugs you recall seeing that appear important and must be fixed? 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
