Re: [Python-Dev] Python Language Summit at PyCon: Agenda
Hi all, I won't be able to make it to the summit and probably not the conference. I have a raging 104F fever (40C for many of you =) The doctor says I have influenza and am highly contagious, so I shouldn't be going anywhere near conference full of people for five days - looks like I'm missing this one :( I may make it down for a couple of sprint days. -Frank ___ 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 Language Summit at PyCon: Agenda
On 5 Mar 2013, at 05:39, Jeff Hardy jdha...@gmail.com wrote: On Mon, Mar 4, 2013 at 4:39 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 1 Mar 2013, at 18:38, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 1 Mar 2013 09:32:23 -0500 Barry Warsaw ba...@python.org wrote: On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed through some. This may still need to be checked in that way (there's are still checks of if os.name == 'nt' right?) Yeah, but that all old code ;) Hmm, what do you mean? `os.name == 'nt'` is still the proper way to test that we're running on a Windows system (more accurately, over the Windows API). It has been used incorrectly in a few places in the Python standard library - Windows support code that would work correctly on IronPython is skipped because os.name is *not* 'nt' on IronPython. That was the case in the past anyway. It's quite some time since I've used IronPython now. I think you misremembered - there's lots of code that uses `sys.platform == 'win32'` to detect Windows, but sys.platform is 'cli' for IronPython. I'm pretty sure `os.name has always been 'nt' (when running on Windows), and if not, it definitely is now. Jython sets os.name to 'java' (IIRC), so there isn't a uniform way to detect Windows across all implementations. Ah, I'm sure you're correct. Thanks. - Jeff -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 9:39 PM, Jeff Hardy jdha...@gmail.com wrote: I think you misremembered - there's lots of code that uses `sys.platform == 'win32'` to detect Windows, but sys.platform is 'cli' for IronPython. I'm pretty sure `os.name has always been 'nt' (when running on Windows), and if not, it definitely is now. Jython sets os.name to 'java' (IIRC), so there isn't a uniform way to detect Windows across all implementations. I've been thinking that this is a bit of a historical mistake on our part. I'm strongly considering setting os.name properly in Jython3. -Frank ___ 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 Language Summit at PyCon: Agenda
On Tue, Mar 5, 2013 at 8:55 AM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: I've been thinking that this is a bit of a historical mistake on our part. I'm strongly considering setting os.name properly in Jython3. In fairness to Jython implementers past - it wasn't a mistake but a deliberate design choice at the time since in the old days we where going for the now defunct 100% Java thing (does anyone remember that?) so this is more of the design has evolved such that Jython's os.name now feels incorrect. I'll stop having conversations with myself in public now, sorry :) -Frank ___ 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 Language Summit at PyCon: Agenda
Le Mon, 4 Mar 2013 19:46:07 +1300, Robert Collins robe...@robertcollins.net a écrit : On 4 March 2013 19:40, Nick Coghlan ncogh...@gmail.com wrote: Your feedback on http://bugs.python.org/issue16997 would be greatly appreciated. Done directly to Antoine on IRC the other day in a conversation with him and Michael about the compatability impact of subtests. Happy to do a full code review if that would be useful. Indeed and some of the changes in the latest patch stem from that conversation. 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] Python Language Summit at PyCon: Agenda
On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. -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] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? ___ 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 Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 4:34 PM, Brett Cannon br...@python.org wrote: On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? It is not always obvious how to test a package when one is not familiar with it. Are the tests in pkgname/tests or tests or ... ? In the scientific community, we have used the convention of making the test suite available at runtime with pkgname.tests(). 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] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 11:44 AM, David Cournapeau courn...@gmail.comwrote: On Mon, Mar 4, 2013 at 4:34 PM, Brett Cannon br...@python.org wrote: On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? It is not always obvious how to test a package when one is not familiar with it. Are the tests in pkgname/tests or tests or ... ? I would argue that's a packaging problem and not a testing infrastructure in the stdlib problem. If we want to standardize on always having the tests in a 'tests' sub-package that's fine, but I don't see unittest or subtest directly controlling that short of some registration hook that has to be called to declare where the tests are. ___ 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 Language Summit at PyCon: Agenda
On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote: And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? I should have added from the command line. E.g. is it: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. Cheers, -Barry signature.asc Description: 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 Language Summit at PyCon: Agenda
On Mon, 4 Mar 2013 11:51:04 -0500 Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote: And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? I should have added from the command line. E.g. is it: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. 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] Python Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 8:41 PM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 4 Mar 2013 11:51:04 -0500 Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote: And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? I should have added from the command line. E.g. is it: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Regards Antoine. Please pick a different name though, pytest is already widely used. ___ 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 Language Summit at PyCon: Agenda
On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? One thing to keep in mind is how to invoke this on a system with multiple versions of Python available. For example, in Debian, a decision was recently made to drop all the nosetests-X.Y scripts from /usr/bin[1]. This makes sense when you think about having at least two major versions of Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), *plus* debug versions of each. Add to that, we don't actually know at package build time which versions of Python you might have installed on your system. A suggestion was made to provide a main entry point so that `pythonX.Y -m nose` would work, which makes sense to me and was adopted by the nose-devs[2]. So while a top level `pytest` command may make sense, it also might not ;). While PEP 426 has a way to declare test dependencies (a good thing), it seems to have no way to declare how to actually run the tests. Cheers, -Barry [1] Start of thread: http://comments.gmane.org/gmane.linux.debian.devel.python/8572 [2] https://github.com/nose-devs/nose/issues/634 ___ 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 Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? There is an open issue on the tracker: http://bugs.python.org/issue14266 --Berker ___ 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 Language Summit at PyCon: Agenda
On 5 March 2013 05:34, Brett Cannon br...@python.org wrote: On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? Three reasons a) There are some bugs (all filed I think) - I intend to hack on these in the near future - that prevent discovery working at all for some use cases. b) discovery requires magic parameters that are project specific (e.g. is it 'discover .' or 'discover . lib' to run it). This is arguably a setup.py/packaging entrypoint issue. c) Test suites written for e.g. Twisted, or nose, or other non-stdunit-runner-compatible test runners will fail to execute even when discovered correctly. There are ways to solve this without addressing a/b/c - just defining a standard command to run that signals success/failure with it's exit code. Packages can export a particular flavour of that in their setup.py if they have exceptional needs, and do nothing in the common case. That doesn't solve 'how to introspect a package test suite' but for distro packagers - and large scale CI integration - that doesn't matter. For instance testrepository offers a setuptools extension to let it be used trivially, I believe nose does something similar. Having something that would let *any* test suite spit out folk's favourite test protocol de jour would be brilliant of course :). [junit-xml, subunit, TAP, ...] -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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 Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 2:26 PM, Berker Peksağ berker.pek...@gmail.com wrote: On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? There is an open issue on the tracker: http://bugs.python.org/issue14266 --Berker setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. ___ 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 Language Summit at PyCon: Agenda
On 5 March 2013 05:51, Barry Warsaw ba...@python.org wrote: I should have added from the command line. E.g. is it: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y $ testr run :) Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. pimping own horse If there is a .testr.conf you can run 'testr init; testr run'. Thats the defined entry point for testr, and .testr.conf can specify running make, or setup.py build or whatever else is needed to run tests. /pimp I would love to see a declaritive interface so that you can tell that is what you should run. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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 Language Summit at PyCon: Agenda
On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote: setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. Shouldn't testing be a first order feature? -Barry signature.asc Description: 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 Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote: setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. Shouldn't testing be a first order feature? Unfortunately there are so many potential first-order features that we've had to leave some out in order to save time. How to run the tests is not something that you need to know when searching PyPI for a distribution and its dependencies. ___ 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 Language Summit at PyCon: Agenda
On Mar 04, 2013, at 03:40 PM, Daniel Holth wrote: On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote: setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. Shouldn't testing be a first order feature? Unfortunately there are so many potential first-order features that we've had to leave some out in order to save time. How to run the tests is not something that you need to know when searching PyPI for a distribution and its dependencies. Although has unittests that I can run might be a deciding factor of which of the many implementations of a particular feature you might choose. -Barry signature.asc Description: 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 Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 3:45 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 03:40 PM, Daniel Holth wrote: On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote: setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. Shouldn't testing be a first order feature? Unfortunately there are so many potential first-order features that we've had to leave some out in order to save time. How to run the tests is not something that you need to know when searching PyPI for a distribution and its dependencies. Although has unittests that I can run might be a deciding factor of which of the many implementations of a particular feature you might choose. Sure, but that has nothing to do with programmatic package discovery. That's something you will have to do as a person in making a qualitative decision along the same lines as API design. Flipping a bit in a config file saying I have tests doesn't say much beyond you flipped a bit, e.g. no idea on coverage, quality, etc. ___ 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 Language Summit at PyCon: Agenda
On Mar 04, 2013, at 05:04 PM, Brett Cannon wrote: Sure, but that has nothing to do with programmatic package discovery. That's something you will have to do as a person in making a qualitative decision along the same lines as API design. Flipping a bit in a config file saying I have tests doesn't say much beyond you flipped a bit, e.g. no idea on coverage, quality, etc. What I'm looking for is something that automated tools can use to easily discover how to run a package's tests. I want it to be dead simple for developers of a package to declare how their tests are to be run, and what extra dependencies they might need. It seems like PEP 426 only addresses the latter. Maybe that's fine and a different PEP is needed to describe automated test discover, but I still think it's an important use case. Imagine: * Every time you upload a package to PyPI, snakebite runs your test suite on a variety of Python versions and platforms. You get a nice link to the Jenkins results so you and your users get a good sense of overall package quality. * You have an automated gatekeeper that will prevent commits or uploads if your coverage or test results get worse instead of better. * Distro packagers can build tools that auto-discover the tests so that they are run automatically when the package is built, ensuring high quality packages specifically targeted to those distros. As a community, we know how important tests are, so I think our tools should reflect that and make it easy for those tests to be expressed. As a selfish side-effect, I want to reduce the amount of guesswork I need to perform in order to know how to run a package's test when I `$vcs clone` their repository. ;) Cheers, -Barry signature.asc Description: 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 Language Summit at PyCon: Agenda
On 3 Mar 2013, at 01:29, Trent Nelson tr...@snakebite.org wrote: On Wed, Feb 27, 2013 at 08:51:16AM -0800, Michael Foord wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. Hmm, seems like this might be a good forum to introduce the parallel/async stuff I've been working on the past few months. TL;DR version is I've come up with an alternative approach for exploiting multiple cores that doesn't rely on GIL-removal or STM (and has a negligible performance overhead when executing single-threaded code). (For those that are curious, it lives in the px branch of the sandbox/trent repo on hg.p.o, albeit in a very experimental/prototype/proof-of-concept state (i.e. it's an unorganized, undocumented, uncommented hackfest); on the plus side, it works. Sort of.) Second suggestion: perhaps a little segment on Snakebite? What it is, what's available to committers, feedback/kvetching from those who have already used it, etc. I've added both to the agenda. (I forgot the format of these summits -- is there a projector?) I've asked for a projector, yes. Michael Trent. -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 3/4/2013 5:24 PM, Barry Warsaw wrote: What I'm looking for is something that automated tools can use to easily discover how to run a package's tests. I want it to be dead simple for developers of a package to declare how their tests are to be run, and what I am writing a package that has tests for each module (which I so far run individually for each module) using a custom test framework. I am planning to add a function to the package to run all of them. Should I call it 'testall', 'test_all', 'runtests', or something else? I really do not care. It would be used like this. import xxx; xxx.testall() Of course, this would not work with the stdlib since /lib is not a package that can be imported. I could put the same code in the top level of a module, to be run when imported (but that would not work with re-imports), or put the function in my test module. I am willing to adjust to a standard when there is one. What I do suggest is that package developers should only have to provide one standard entry point that hides all package-specific details. I presume the side-effect spec would be error messages to sdterr. Any return requirements should be a simple as possible, as in all pass True/False, or (number run, number fail) by whatever counting method the package/test framework uses. (Note: my framework does not count tests, as I only care about failure messages, but testall could count modules tested and those with a failure.) extra dependencies they might need. It seems like PEP 426 only addresses the latter. Maybe that's fine and a different PEP is needed to describe automated test discover, but I still think it's an important use case. New PEP. -- Terry Jan Reedy ___ 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 Language Summit at PyCon: Agenda
On 5 Mar 2013 05:21, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? One thing to keep in mind is how to invoke this on a system with multiple versions of Python available. For example, in Debian, a decision was recently made to drop all the nosetests-X.Y scripts from /usr/bin[1]. This makes sense when you think about having at least two major versions of Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), *plus* debug versions of each. Add to that, we don't actually know at package build time which versions of Python you might have installed on your system. A suggestion was made to provide a main entry point so that `pythonX.Y -m nose` would work, which makes sense to me and was adopted by the nose-devs[2]. So while a top level `pytest` command may make sense, it also might not ;). While PEP 426 has a way to declare test dependencies (a good thing), it seems to have no way to declare how to actually run the tests. Metadata 2.0 won't cover that, 2.1 probably will. Please give us time to solve problems incrementally rather than trying to fix everything at once. Regards, Nick. Cheers, -Barry [1] Start of thread: http://comments.gmane.org/gmane.linux.debian.devel.python/8572 [2] https://github.com/nose-devs/nose/issues/634 ___ 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] Python Language Summit at PyCon: Agenda
On 4 Mar 2013, at 06:26, Robert Collins robe...@robertcollins.net wrote: On 4 March 2013 18:54, Guido van Rossum gu...@python.org wrote: On Sun, Mar 3, 2013 at 9:24 PM, Robert Collins robe...@robertcollins.net wrote: I'd like to talk about overhauling - not tweaking, overhauling - the standard library testing facilities. That seems like too big a topic and too vague a description to discuss usefully. Perhaps you have a specific proposal? Or at least just a use case that's poorly covered? I have both - I have a draft implementation for a new test result API (and forwards and backwards compat code etc), and use cases that drive it. I started a thread here - http://lists.idyll.org/pipermail/testing-in-python/2013-February/005434.html , with blog posts https://rbtcollins.wordpress.com/2013/02/14/time-to-revise-the-subunit-protocol/ https://rbtcollins.wordpress.com/2013/02/15/more-subunit-needs/ https://rbtcollins.wordpress.com/2013/02/19/first-experience-implementing-streamresult/ https://rbtcollins.wordpress.com/2013/02/23/simpler-is-better/ They are focused on subunit, but much of subunit's friction has been due to issues encountered from the stdlibrary TestResult API - in particular three things: - the single-active-test model that the current API (or at least implementation) has. - the expectation that all test outcomes will originate from the same interpreter (or something with a live traceback object) - the inability to supply details about errors other than the exception All of which start to bite rather deep when working on massively parallel test environments. It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. TBH, your choice of words is ambiguous -- are you interested in overhauling the facilities for testing *of* the standard library (i.e. the 'test' package), or the testing facilities *provided by* the standard library (i.e. the unittest module)? Sorry! Testing facilities provided by the standard library. They should naturally facilitate testing of the standard library too. We can certainly talk about it - although as Guido says, something specific may be easier to have a useful discussion about. Reading through your blog articles it seemed like a whole lot of subunit context was required to understand the specific proposal you're making for the TestResult. It also *seems* like you're redesigning the TestResult for a single use case (distributed testing) with an api that looks quite odd for anything that isn't that use case. I'd rather see how we can make the TestResult play *better* with those requirements. That discussion probably belongs in another thread - or at the summit. Michael -Rob -- --Guido van Rossum (python.org/~guido) -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 4 Mar 2013, at 19:26, Berker Peksağ berker.pek...@gmail.com wrote: On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? There is an open issue on the tracker: http://bugs.python.org/issue14266 Indeed, and unittest2 (the backport) which has to work with Python 2.6 (where python -m package_name doesn't work) has unit2 as a shortcut. So it has an advantage over the standard library version here. I'd like to see pyunit as a short-cut for python -m unittest discover, with a pyunit-3.x variant too. Barry objects that Linux distributions won't want to support all of these, which is frankly their problem. Michael --Berker ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 5 March 2013 13:21, Michael Foord fuzzy...@voidspace.org.uk wrote: We can certainly talk about it - although as Guido says, something specific may be easier to have a useful discussion about. Reading through your blog articles it seemed like a whole lot of subunit context was required to understand the specific proposal you're making for the TestResult. It also *seems* like you're redesigning the TestResult for a single use case (distributed testing) with an api that looks quite odd for anything that isn't that use case. I'd rather see how we can make the TestResult play *better* with those requirements. That discussion probably belongs in another thread - or at the summit. Right - all I wanted was to flag that you and I and any other interested parties should discuss this at the summit :). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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 Language Summit at PyCon: Agenda
On 28 Feb 2013, at 13:49, Brett Cannon br...@python.org wrote: On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. While Christian is in the best position to discuss this, I did review his various monkeypatch fixes + expat patches so I can attempt to answer any questions people may have. I've put you next to the topic in the agenda Brett :-) Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 4 Mar 2013, at 20:02, Daniel Holth dho...@gmail.com wrote: On Mon, Mar 4, 2013 at 2:26 PM, Berker Peksağ berker.pek...@gmail.com wrote: On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote: $ python -m unittest discover $ python setup.py test $ python setup.py nosetests $ python -m nose test $ nosetests-X.Y Besides having a multitude of choices, there's almost no way to automatically discover (e.g. by metadata inspection or some such) how to invoke the tests. You're often lucky if there's a README.test and it's still accurate. I hope we can have a pytest utility that does the right thing in 3.4 :-) Typing python -m unittest discover is too cumbersome. Where is this work being done (e.g. is there a PEP)? There is an open issue on the tracker: http://bugs.python.org/issue14266 --Berker setup.py's setup(test_suite=x)... not sure if this is a distutils or setuptools feature. PEP 426 has an extension mechanism that could do the job. This is a setuptools extension. There was some discussion for packaging/distutils2 of having test support but I have no idea if that has been picked up for the new bunch of packaging related work. Michael ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 1 Mar 2013, at 18:38, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 1 Mar 2013 09:32:23 -0500 Barry Warsaw ba...@python.org wrote: On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed through some. This may still need to be checked in that way (there's are still checks of if os.name == 'nt' right?) Yeah, but that all old code ;) Hmm, what do you mean? `os.name == 'nt'` is still the proper way to test that we're running on a Windows system (more accurately, over the Windows API). It has been used incorrectly in a few places in the Python standard library - Windows support code that would work correctly on IronPython is skipped because os.name is *not* 'nt' on IronPython. That was the case in the past anyway. It's quite some time since I've used IronPython now. Michael 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 5 Mar 2013, at 00:23, Robert Collins robe...@robertcollins.net wrote: On 5 March 2013 13:21, Michael Foord fuzzy...@voidspace.org.uk wrote: We can certainly talk about it - although as Guido says, something specific may be easier to have a useful discussion about. Reading through your blog articles it seemed like a whole lot of subunit context was required to understand the specific proposal you're making for the TestResult. It also *seems* like you're redesigning the TestResult for a single use case (distributed testing) with an api that looks quite odd for anything that isn't that use case. I'd rather see how we can make the TestResult play *better* with those requirements. That discussion probably belongs in another thread - or at the summit. Right - all I wanted was to flag that you and I and any other interested parties should discuss this at the summit :). I've added a testing topic to the agenda. At the very least you could outline your streaming test result proposal, or kick off a meta discussion. We'll probably time limit the discussion so some specific focus will make it more productive - or maybe you can get a feel for how open to major changes in this area other python devs are. Michael -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 5 March 2013 13:50, Michael Foord fuzzy...@voidspace.org.uk wrote: Right - all I wanted was to flag that you and I and any other interested parties should discuss this at the summit :). I've added a testing topic to the agenda. At the very least you could outline your streaming test result proposal, or kick off a meta discussion. We'll probably time limit the discussion so some specific focus will make it more productive - or maybe you can get a feel for how open to major changes in this area other python devs are. Cool. I can step through the core use cases and differences to what TestResult is in pretty short order. We can spider out from there as folk desire. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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 Language Summit at PyCon: Agenda
On 4 Mar 2013, at 22:24, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 05:04 PM, Brett Cannon wrote: Sure, but that has nothing to do with programmatic package discovery. That's something you will have to do as a person in making a qualitative decision along the same lines as API design. Flipping a bit in a config file saying I have tests doesn't say much beyond you flipped a bit, e.g. no idea on coverage, quality, etc. What I'm looking for is something that automated tools can use to easily discover how to run a package's tests. I want it to be dead simple for developers of a package to declare how their tests are to be run, and what extra dependencies they might need. It seems like PEP 426 only addresses the latter. Maybe that's fine and a different PEP is needed to describe automated test discover, but I still think it's an important use case. Imagine: * Every time you upload a package to PyPI, snakebite runs your test suite on a variety of Python versions and platforms. You get a nice link to the Jenkins results so you and your users get a good sense of overall package quality. * You have an automated gatekeeper that will prevent commits or uploads if your coverage or test results get worse instead of better. * Distro packagers can build tools that auto-discover the tests so that they are run automatically when the package is built, ensuring high quality packages specifically targeted to those distros. As a community, we know how important tests are, so I think our tools should reflect that and make it easy for those tests to be expressed. As a selfish side-effect, I want to reduce the amount of guesswork I need to perform in order to know how to run a package's test when I `$vcs clone` their repository. ;) Distutils2 had a way of specifying this in the metadata. It looks like this hasn't made it into the reboot: http://alexis.notmyidea.org/distutils2/distutils/newcommands.html Michael 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 4 Mar 2013, at 20:00, Robert Collins robe...@robertcollins.net wrote: On 5 March 2013 05:34, Brett Cannon br...@python.org wrote: On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw ba...@python.org wrote: On Mar 04, 2013, at 07:26 PM, Robert Collins wrote: It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. And One True Way of invoking and/or discovering how to invoke, a package's test suite. How does unittest's test discovery not solve that? Three reasons a) There are some bugs (all filed I think) - I intend to hack on these in the near future - that prevent discovery working at all for some use cases. The only discovery related issues I'm aware of are: * Issue 16079 (filed by you) - trivial to fix just needs a test * Issue 15010 obscure and unlikely to be an issue for standard discovery I'm not aware of any other discovery related issues. Please let me know (or add me as nosy) to them. b) discovery requires magic parameters that are project specific (e.g. is it 'discover .' or 'discover . lib' to run it). This is arguably a setup.py/packaging entrypoint issue. This was addressed by Barry - and yes discovery has to be done with the right parameters. If you layout your project in a particular way then python -m unittest discover in the project root will just work. This is project specific metadata though and not a particular problem of any testing library. c) Test suites written for e.g. Twisted, or nose, or other non-stdunit-runner-compatible test runners will fail to execute even when discovered correctly. There are ways to solve this without addressing a/b/c - just defining a standard command to run that signals success/failure with it's exit code. Packages can export a particular flavour of that in their setup.py if they have exceptional needs, and do nothing in the common case. That doesn't solve 'how to introspect a package test suite' but for distro packagers - and large scale CI integration - that doesn't matter. For instance testrepository offers a setuptools extension to let it be used trivially, I believe nose does something similar. unittest2 also has setuptools compatible test command. Having something that would let *any* test suite spit out folk's favourite test protocol de jour would be brilliant of course :). [junit-xml, subunit, TAP, ...] Yes. Michael -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 4:39 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 1 Mar 2013, at 18:38, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 1 Mar 2013 09:32:23 -0500 Barry Warsaw ba...@python.org wrote: On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed through some. This may still need to be checked in that way (there's are still checks of if os.name == 'nt' right?) Yeah, but that all old code ;) Hmm, what do you mean? `os.name == 'nt'` is still the proper way to test that we're running on a Windows system (more accurately, over the Windows API). It has been used incorrectly in a few places in the Python standard library - Windows support code that would work correctly on IronPython is skipped because os.name is *not* 'nt' on IronPython. That was the case in the past anyway. It's quite some time since I've used IronPython now. I think you misremembered - there's lots of code that uses `sys.platform == 'win32'` to detect Windows, but sys.platform is 'cli' for IronPython. I'm pretty sure `os.name has always been 'nt' (when running on Windows), and if not, it definitely is now. Jython sets os.name to 'java' (IIRC), so there isn't a uniform way to detect Windows across all implementations. - Jeff ___ 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 Language Summit at PyCon: Agenda
Stefan Krah, 02.03.2013 21:01: Stefan Behnel wrote: I'm not so happy with the argument clinic, but that's certainly also because I'm biased. I've written the argument unpacking code for Cython some years ago, so it's not surprising that I'm quite happy with that and fail to see the need for a totally new DSL *and* a totally new implementation, especially with its mapping to the slowish ParseTuple*() C-API functions. I've also not seen a good argument why the existing Py3 function signatures can't do what the proposed DSL tries to achieve. They'd at least make it clear that the intention is to make things more Python-like, and would at the same time provide the documentation. That's why Stefan Krah is writing a competing PEP - a number of us already agree with you, and think the case needs to be made for choosing something completely different like Argument Clinic I'll happily provide my feedback to that approach. It might also have a positive impact on the usage of Py3 argument annotations, which I think merit some more visibility and useful use cases. BTW, I think so far no one has stepped forward to implement the custom argument handlers. I've looked at Cython output and, as you say, most of it is there already. Is it possible to write a minimal version of the code generator that just produces the argument handling code? It should be possible, although it does have a lot of dependencies on Cython's type system, so a part of that would have to be extracted as well or at least emulated. Conversion functions are based on it, for example. However, I think it would actually be easiest to just let Cython generate the module interface completely. I.e. you'd remove all code that currently deals with Python function signatures from the C module, only leaving the bare C API, and then generate a Cython interface module like this: cdef extern from *: object original_c_xyzfunc(object x, int y, double z) def xyzfunc(x, int y=0, *, double z=1.0): docstring goes here return original_c_xyzfunc(x,y,z) Finally, #include the generated C file at the end of the original module. There'd be a bit of a hassle with the module init function, I guess. Maybe renaming it in the Cython C code (even just a #define) and calling it from the original module would work. Or do it the other way round and add a hook function somewhere that does the manually written parts of the module setup. Sounds simple enough in both cases, although I'm sure there's lots of little details. Extension types and their methods are certainly part of those details ... Stefan ___ 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 Language Summit at PyCon: Agenda
On Mar 2, 2013, at 11:41 AM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Mar 1, 2013 at 9:39 AM, Doug Hellmann doug.hellm...@gmail.com wrote: On Feb 27, 2013, at 11:51 AM, Michael Foord wrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) Since the time I suggested we add packaging to the agenda, Nick has set up a separate summit meeting for Friday evening. I don't know if it makes sense to leave this on the agenda for Wednesday or not. Nick, what do you think? I think it's definitely worth my taking some time to explain my goals for the Friday night session, and some broader things in terms of where I'd like to see packaging going, but a lot of the key packaging people aren't involved in Python language development *per se*, and hence won't be at the language summit. OK, a summary seems like a good idea. There's also one controversial point that *does* need to be raised at the summit: I would like to make distutils-sig the true authority for packaging standards, so we can stop cross-posting PEPs intended to apply to packaging in *current* versions of Python to python-dev. The split discussions suck, and most of the people that need to be convinced in order for packaging standards to be supported in current versions of Python aren't on python-dev, since it's a tooling issue rather than a language design issue. Standard lib support is necessary in the long run to provide a good batteries included experience, but it's *not* the way to create the batteries in the first place. Until these standards have been endorsed by the authors of *existing* packaging tools, proposing them for stdlib addition is premature, but has been perceived as necessary in the past due to the confused power structure. +1 -- anything to reduce the confusion about where to get involved :) This means that those core developers that want a say in the future direction of packaging and distribution of Python software would need to be actively involved in the ongoing discussions on distutils-sig, rather than relying on being given an explicit invitation to weigh in at the last minute through a thread (or threads) on python-dev. The requirement that BDFL-delegates for packaging and distribution related PEPs also be experienced core developers will remain, however, as suitable for future stdlib inclusion is an important overarching requirement for packaging and distribution standards. Such delegates will just be expected to participate actively in distutils-sig *as well as* python-dev. Proposals for *actual* standard library updates (to bring it into line with updated packaging standards) would still be subject to python-dev discussion and authority (and would *not* have their Discussions-To header set). Such discussions aren't particularly relevant to most of the packaging tool developers, since the standard library version isn't updated frequently enough to be useful to them, and also isn't available on older Python releases, so python-dev is a more appropriate venue from both perspectives. At the moment, python-dev, catalog-sig and distutils-sig create an awkward trinity where decision making authority and the appropriate venues for discussion are grossly unclear. I consider this to be one of the key reasons that working on packaging issues has quite a high incidence of developer burnout - it's hard to figure out who needs to be convinced of what, so it's easy for the frustration levels to reach the this just isn't worth the hassle stage (especially when trying to bring python-dev members up to speed on discussions that may have taken months on distutils-sig, and when many of the details are awkward compromises forced by the need to support *existing* tools and development processes on older versions of Python). Under my proposal, the breakdown would be slightly clearer: distutils-sig: overall authority for packaging and distribution related standards, *including* the interfaces between index servers (such as PyPI) and automated tools. If a PEP has Discussions-To set to distutils-sig, announcements of new PEPs, new versions of those PEPs, *and* their acceptance or rejection should be announced there, and *not* on python-dev. The Resolution header will thus point to a distutils-sig post rather than a python-dev one. distutils-sig will focus on solutions that work for *current* versions of Python, while keeping in mind the need for future stdlib support. python-dev: authority over stdlib support for packaging and distribution standards, and the
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On 28 February 2013 05:51, Michael Foord mich...@voidspace.org.uk wrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. I'd like to talk about overhauling - not tweaking, overhauling - the standard library testing facilities. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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 Language Summit at PyCon: Agenda
On Sun, Mar 3, 2013 at 9:24 PM, Robert Collins robe...@robertcollins.net wrote: I'd like to talk about overhauling - not tweaking, overhauling - the standard library testing facilities. That seems like too big a topic and too vague a description to discuss usefully. Perhaps you have a specific proposal? Or at least just a use case that's poorly covered? TBH, your choice of words is ambiguous -- are you interested in overhauling the facilities for testing *of* the standard library (i.e. the 'test' package), or the testing facilities *provided by* the standard library (i.e. the unittest module)? -- --Guido van Rossum (python.org/~guido) ___ 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 Language Summit at PyCon: Agenda
On 4 March 2013 18:54, Guido van Rossum gu...@python.org wrote: On Sun, Mar 3, 2013 at 9:24 PM, Robert Collins robe...@robertcollins.net wrote: I'd like to talk about overhauling - not tweaking, overhauling - the standard library testing facilities. That seems like too big a topic and too vague a description to discuss usefully. Perhaps you have a specific proposal? Or at least just a use case that's poorly covered? I have both - I have a draft implementation for a new test result API (and forwards and backwards compat code etc), and use cases that drive it. I started a thread here - http://lists.idyll.org/pipermail/testing-in-python/2013-February/005434.html , with blog posts https://rbtcollins.wordpress.com/2013/02/14/time-to-revise-the-subunit-protocol/ https://rbtcollins.wordpress.com/2013/02/15/more-subunit-needs/ https://rbtcollins.wordpress.com/2013/02/19/first-experience-implementing-streamresult/ https://rbtcollins.wordpress.com/2013/02/23/simpler-is-better/ They are focused on subunit, but much of subunit's friction has been due to issues encountered from the stdlibrary TestResult API - in particular three things: - the single-active-test model that the current API (or at least implementation) has. - the expectation that all test outcomes will originate from the same interpreter (or something with a live traceback object) - the inability to supply details about errors other than the exception All of which start to bite rather deep when working on massively parallel test environments. It is of course possible for subunit and related tools to run their own implementation, but it seems ideal to me to have a common API which regular unittest, nose, py.test and others can all agree on and use : better reuse for pretty printers, GUI displays and the like depend on some common API. TBH, your choice of words is ambiguous -- are you interested in overhauling the facilities for testing *of* the standard library (i.e. the 'test' package), or the testing facilities *provided by* the standard library (i.e. the unittest module)? Sorry! Testing facilities provided by the standard library. They should naturally facilitate testing of the standard library too. -Rob -- --Guido van Rossum (python.org/~guido) -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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 Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 4:26 PM, Robert Collins robe...@robertcollins.net wrote: On 4 March 2013 18:54, Guido van Rossum gu...@python.org wrote: On Sun, Mar 3, 2013 at 9:24 PM, Robert Collins robe...@robertcollins.net wrote: I'd like to talk about overhauling - not tweaking, overhauling - the standard library testing facilities. That seems like too big a topic and too vague a description to discuss usefully. Perhaps you have a specific proposal? Or at least just a use case that's poorly covered? I have both - I have a draft implementation for a new test result API (and forwards and backwards compat code etc), and use cases that drive it. I started a thread here - http://lists.idyll.org/pipermail/testing-in-python/2013-February/005434.html , with blog posts https://rbtcollins.wordpress.com/2013/02/14/time-to-revise-the-subunit-protocol/ https://rbtcollins.wordpress.com/2013/02/15/more-subunit-needs/ https://rbtcollins.wordpress.com/2013/02/19/first-experience-implementing-streamresult/ https://rbtcollins.wordpress.com/2013/02/23/simpler-is-better/ They are focused on subunit, but much of subunit's friction has been due to issues encountered from the stdlibrary TestResult API - in particular three things: - the single-active-test model that the current API (or at least implementation) has. - the expectation that all test outcomes will originate from the same interpreter (or something with a live traceback object) - the inability to supply details about errors other than the exception All of which start to bite rather deep when working on massively parallel test environments. Your feedback on http://bugs.python.org/issue16997 would be greatly appreciated. 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] Python Language Summit at PyCon: Agenda
On 4 March 2013 19:40, Nick Coghlan ncogh...@gmail.com wrote: Your feedback on http://bugs.python.org/issue16997 would be greatly appreciated. Done directly to Antoine on IRC the other day in a conversation with him and Michael about the compatability impact of subtests. Happy to do a full code review if that would be useful. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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 Language Summit at PyCon: Agenda
On Mon, Mar 4, 2013 at 4:46 PM, Robert Collins robe...@robertcollins.net wrote: On 4 March 2013 19:40, Nick Coghlan ncogh...@gmail.com wrote: Your feedback on http://bugs.python.org/issue16997 would be greatly appreciated. Done directly to Antoine on IRC the other day in a conversation with him and Michael about the compatability impact of subtests. Happy to do a full code review if that would be useful. The extra set of eyes couldn't hurt (and if you can spot a better way to tie @expectedfailure into the rest of the test running machinery, that would be great. Making sure that decorator doesn't break is the ugliest part of the whole patch) 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] Python Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 1:15 AM, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Feb 28, 2013 at 1:37 PM, Barry Warsaw ba...@python.org wrote: On Feb 27, 2013, at 11:33 AM, fwierzbi...@gmail.com wrote: The easy part for Jython is pushing some of our if is_jython: stuff into the appropriate spots in CPython's Lib/. I wonder if there isn't a better way to do this than sprinkling is_jython, is_pypy, is_ironpython, is_thenextbigthing all over the code base. I have no bright ideas here, but it seems like a feature matrix would be a better way to go than something that assumes a particular Python implementation has a particular feature set (which may change in the future). Yes, avoiding that kind of thing is a key motivation for sys.implementation. Any proposal for is_jython blocks should instead be reformulated as a proposal for new sys.implementation attributes. I kind of wish there were an assert-like magic if __debug__: type of mechanism behind this so that blocks of code destined solely for a single interpreter won't be seen in the code objects or .pyc's of non-target interpreters. That idea obviously isn't fleshed out but i figure i'd better plant the seed... It'd mean smaller code objects and less bloat from constants (docstrings for one implementation vs another, etc) being in memory. Taken further, this could even be extended beyond implementations to platforms as we have some standard library code with alternate definitions within one file for windows vs posix, etc. Antoine's point about code like that being untestable by most CPython developers is valid. I'd want --with-pydebug builds to disable any parsing - code object exclusions to at least make sure its syntax doesn't rot but that still doesn't _test_ it unless we get someone maintains reliable buildbots for every implementation using this common stdlib. -gps ___ 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 Language Summit at PyCon: Agenda
On Fri, Mar 1, 2013 at 9:39 AM, Doug Hellmann doug.hellm...@gmail.com wrote: On Feb 27, 2013, at 11:51 AM, Michael Foord wrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) Since the time I suggested we add packaging to the agenda, Nick has set up a separate summit meeting for Friday evening. I don't know if it makes sense to leave this on the agenda for Wednesday or not. Nick, what do you think? I think it's definitely worth my taking some time to explain my goals for the Friday night session, and some broader things in terms of where I'd like to see packaging going, but a lot of the key packaging people aren't involved in Python language development *per se*, and hence won't be at the language summit. There's also one controversial point that *does* need to be raised at the summit: I would like to make distutils-sig the true authority for packaging standards, so we can stop cross-posting PEPs intended to apply to packaging in *current* versions of Python to python-dev. The split discussions suck, and most of the people that need to be convinced in order for packaging standards to be supported in current versions of Python aren't on python-dev, since it's a tooling issue rather than a language design issue. Standard lib support is necessary in the long run to provide a good batteries included experience, but it's *not* the way to create the batteries in the first place. Until these standards have been endorsed by the authors of *existing* packaging tools, proposing them for stdlib addition is premature, but has been perceived as necessary in the past due to the confused power structure. This means that those core developers that want a say in the future direction of packaging and distribution of Python software would need to be actively involved in the ongoing discussions on distutils-sig, rather than relying on being given an explicit invitation to weigh in at the last minute through a thread (or threads) on python-dev. The requirement that BDFL-delegates for packaging and distribution related PEPs also be experienced core developers will remain, however, as suitable for future stdlib inclusion is an important overarching requirement for packaging and distribution standards. Such delegates will just be expected to participate actively in distutils-sig *as well as* python-dev. Proposals for *actual* standard library updates (to bring it into line with updated packaging standards) would still be subject to python-dev discussion and authority (and would *not* have their Discussions-To header set). Such discussions aren't particularly relevant to most of the packaging tool developers, since the standard library version isn't updated frequently enough to be useful to them, and also isn't available on older Python releases, so python-dev is a more appropriate venue from both perspectives. At the moment, python-dev, catalog-sig and distutils-sig create an awkward trinity where decision making authority and the appropriate venues for discussion are grossly unclear. I consider this to be one of the key reasons that working on packaging issues has quite a high incidence of developer burnout - it's hard to figure out who needs to be convinced of what, so it's easy for the frustration levels to reach the this just isn't worth the hassle stage (especially when trying to bring python-dev members up to speed on discussions that may have taken months on distutils-sig, and when many of the details are awkward compromises forced by the need to support *existing* tools and development processes on older versions of Python). Under my proposal, the breakdown would be slightly clearer: distutils-sig: overall authority for packaging and distribution related standards, *including* the interfaces between index servers (such as PyPI) and automated tools. If a PEP has Discussions-To set to distutils-sig, announcements of new PEPs, new versions of those PEPs, *and* their acceptance or rejection should be announced there, and *not* on python-dev. The Resolution header will thus point to a distutils-sig post rather than a python-dev one. distutils-sig will focus on solutions that work for *current* versions of Python, while keeping in mind the need for future stdlib support. python-dev: authority over stdlib support for packaging and distribution standards, and the batteries included experience of interacting with those standards. Until a next generation distribution infrastructure is firmly established (which may involve years of running the legacy infrastructure and the next generation metadata 2.x based infrastructure
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Sat, Mar 2, 2013 at 6:01 PM, Gregory P. Smith g...@krypto.org wrote: It'd mean smaller code objects and less bloat from constants (docstrings for one implementation vs another, etc) being in memory. Taken further, this could even be extended beyond implementations to platforms as we have some standard library code with alternate definitions within one file for windows vs posix, etc. To plant seeds in the opposite direction, as you're considering this, I suggest looking at: - environment markers in PEP 345 and 426 for conditional selection based on a constrained set of platform data - compatibility tags in PEP 425 (and consider how they could be used in relation to __pycache__ and bytecode-only distribution of platform specific files) 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] Python Language Summit at PyCon: Agenda
On Fri, Mar 1, 2013 at 7:41 PM, Stefan Behnel stefan...@behnel.de wrote: Michael Foord, 27.02.2013 17:51: It's also true that many of the topics above aren't really interesting for us, because we just inherit them with CPython, e.g. stdlib changes. Packaging is only relevant as far as it impacts the distribution of binary extensions, and the main changes appear to be outside of that area (which doesn't mean it's not truly wonderful that they are happening, Python packaging has seen a lot of great improvements during the last years and I'm very happy to see it getting even better). I'm puzzled by this one. Did you leave out PEP 427 (the wheel format), because it's already approved, and hence not likely to be discussed much at the summit, or because you don't consider it to impact the distribution of binary extensions (which would be rather odd, given the nature of the PEP and the wheel format...) Interpreter initialisation would be interesting and Cython could potentially help in some spots here by making code easier to maintain and optimise, for example. We've had this discussion for the importlib bootstrapping and I'm sure there's more that could be done. It's sad to see so much C-level work go into areas that really don't need to be that low-level. Cython's notion of embedding is the exact opposite of CPython's, so I'm not at all clear on how Cython could help with PEP 432 at all. I'm not so happy with the argument clinic, but that's certainly also because I'm biased. I've written the argument unpacking code for Cython some years ago, so it's not surprising that I'm quite happy with that and fail to see the need for a totally new DSL *and* a totally new implementation, especially with its mapping to the slowish ParseTuple*() C-API functions. I've also not seen a good argument why the existing Py3 function signatures can't do what the proposed DSL tries to achieve. They'd at least make it clear that the intention is to make things more Python-like, and would at the same time provide the documentation. That's why Stefan Krah is writing a competing PEP - a number of us already agree with you, and think the case needs to be made for choosing something completely different like Argument Clinic (especially given Guido's expressed tolerance for the idea of / as a possible marker to indicate that the preceding parameters only support positional arguments - that was in the context of Python discussion where it was eventually deemed not necessary, but becomes interesting again in a C API signature discussion) And I'd really like to see a CPython summit happen at some point. There's so much interesting stuff going on in that area that it's worth getting some people together to move these things forward. Yes, a CPython runtime summit some year would be interesting. 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] Python Language Summit at PyCon: Agenda
And I'd really like to see a CPython summit happen at some point. There's so much interesting stuff going on in that area that it's worth getting some people together to move these things forward. Yes, a CPython runtime summit some year would be interesting. Cheers, Nick. I don't see why CPython-specific stuff can't be discussed on the language summit. After all, everyone can be not interested in a topic X or topic Y. I would be even more than happy to contribute my knowledge about building VMs w.r.t. CPython implementation as much as I could. Cheers, fijal ___ 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 Language Summit at PyCon: Agenda
Hi Nick, thanks for the feedback. Nick Coghlan, 02.03.2013 17:58: On Fri, Mar 1, 2013 at 7:41 PM, Stefan Behnel wrote: Michael Foord, 27.02.2013 17:51: It's also true that many of the topics above aren't really interesting for us, because we just inherit them with CPython, e.g. stdlib changes. Packaging is only relevant as far as it impacts the distribution of binary extensions, and the main changes appear to be outside of that area (which doesn't mean it's not truly wonderful that they are happening, Python packaging has seen a lot of great improvements during the last years and I'm very happy to see it getting even better). I'm puzzled by this one. Did you leave out PEP 427 (the wheel format), because it's already approved, and hence not likely to be discussed much at the summit, or because you don't consider it to impact the distribution of binary extensions (which would be rather odd, given the nature of the PEP and the wheel format...) I admit that the wheel format has been sailing mostly below my radar (I guess much of the discussion about it is buried somewhere in the distutils SIG archives?), but the last time it started blinking brightly enough to have me take a look at the PEP, I didn't really see anything that was relevant enough to Cython to pay much attention or even comment on it. As I understand it, it's almost exclusively about naming and metadata. Cython compiled extensions are in no way different from plain C extensions wrt packaging. What works for those will work for Cython just fine. Does it imply any changes in the build system that I should be aware of? Cython usually just runs as a preprocessor for distutils extensions, before even calling into setup(). The rest is just a plain old distutils extension build. Interpreter initialisation would be interesting and Cython could potentially help in some spots here by making code easier to maintain and optimise, for example. We've had this discussion for the importlib bootstrapping and I'm sure there's more that could be done. It's sad to see so much C-level work go into areas that really don't need to be that low-level. Cython's notion of embedding is the exact opposite of CPython's, so I'm not at all clear on how Cython could help with PEP 432 at all. I wasn't thinking about embedding CPython in a Cython compiled program. That would appear like a rather strange setup here. In the context of importlib, I proposed compiling init time Python code into statically linked extension modules in order to speed it up and make it independent of the parser and interpreter, as an alternative to freezing it (which requires a working VM already and implies interpretation overhead). I agree that Cython can't help in most of the early low-level runtime bootstrap process, but once a minimum runtime is available, the more high-level parts of the initialisation could be done in compiled Python code, which other implementations might be able to reuse. I'm not so happy with the argument clinic, but that's certainly also because I'm biased. I've written the argument unpacking code for Cython some years ago, so it's not surprising that I'm quite happy with that and fail to see the need for a totally new DSL *and* a totally new implementation, especially with its mapping to the slowish ParseTuple*() C-API functions. I've also not seen a good argument why the existing Py3 function signatures can't do what the proposed DSL tries to achieve. They'd at least make it clear that the intention is to make things more Python-like, and would at the same time provide the documentation. That's why Stefan Krah is writing a competing PEP - a number of us already agree with you, and think the case needs to be made for choosing something completely different like Argument Clinic I'll happily provide my feedback to that approach. It might also have a positive impact on the usage of Py3 argument annotations, which I think merit some more visibility and useful use cases. (especially given Guido's expressed tolerance for the idea of / as a possible marker to indicate that the preceding parameters only support positional arguments - that was in the context of Python discussion where it was eventually deemed not necessary, but becomes interesting again in a C API signature discussion) I've not really had that need myself yet, but I remember thinking of it at least once while writing Cython's argument unpacking code. I think it would get rid of a currently existing asymmetry between positional arguments and keyword(-only) arguments, and would remove the risk of naming collisions with positional arguments, most notably when **kwargs is used. And yes, I agree that it would be most interesting for C signatures, just like kwonly arguments are really handy there. It might not be all too hard to write up a prototype in Cython. And I should be able to find a couple of places in lxml where I could use this as an actual feature, so I
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
Stefan Behnel stefan...@behnel.de wrote: I'm not so happy with the argument clinic, but that's certainly also because I'm biased. I've written the argument unpacking code for Cython some years ago, so it's not surprising that I'm quite happy with that and fail to see the need for a totally new DSL *and* a totally new implementation, especially with its mapping to the slowish ParseTuple*() C-API functions. I've also not seen a good argument why the existing Py3 function signatures can't do what the proposed DSL tries to achieve. They'd at least make it clear that the intention is to make things more Python-like, and would at the same time provide the documentation. That's why Stefan Krah is writing a competing PEP - a number of us already agree with you, and think the case needs to be made for choosing something completely different like Argument Clinic I'll happily provide my feedback to that approach. It might also have a positive impact on the usage of Py3 argument annotations, which I think merit some more visibility and useful use cases. BTW, I think so far no one has stepped forward to implement the custom argument handlers. I've looked at Cython output and, as you say, most of it is there already. Is it possible to write a minimal version of the code generator that just produces the argument handling code? Approximately, how many lines of code would we be talking about? 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] Python Language Summit at PyCon: Agenda
On Thu, 28 Feb 2013 11:39:52 + Michael Foord mich...@voidspace.org.uk wrote: Perhaps someone wants to discuss http://www.python.org/dev/peps/pep-0428/, but I won't be there and the PEP isn't terribly up-to-date either :-) If you can find someone familiar with pathlib to champion the discussion it is more likely to happen and be productive... Getting the PEP up to date before the summit will also help. (I very much like the *idea* of pathlib and the bits I've seen / read through - but I haven't used it in anger yet so I don't feel qualified to champion it myself.) I've made the PEP up-to-date now. http://mail.python.org/pipermail/python-ideas/2013-March/019731.html 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] Python Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 08:51:16AM -0800, Michael Foord wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. Hmm, seems like this might be a good forum to introduce the parallel/async stuff I've been working on the past few months. TL;DR version is I've come up with an alternative approach for exploiting multiple cores that doesn't rely on GIL-removal or STM (and has a negligible performance overhead when executing single-threaded code). (For those that are curious, it lives in the px branch of the sandbox/trent repo on hg.p.o, albeit in a very experimental/prototype/proof-of-concept state (i.e. it's an unorganized, undocumented, uncommented hackfest); on the plus side, it works. Sort of.) Second suggestion: perhaps a little segment on Snakebite? What it is, what's available to committers, feedback/kvetching from those who have already used it, etc. (I forgot the format of these summits -- is there a projector?) Trent. ___ 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 Language Summit at PyCon: Agenda
Michael Foord, 27.02.2013 17:51: PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings Hi, as in the years before, none of the Cython developers is attending the PyCon-US, so we won't appear that the language summit either. It's a bit sad that it always takes place at that venue, but I guess there'll just always be people that can't come to one meeting or the other, so PyCon-US would just catch the majority. I think it would still be interesting for many of the attendants to get a status report about Cython, as there seems to be some confusion and incomplete knowledge about what Cython actually is, what we have achieved and where we are heading. But maybe the confusion is large enough to require more than just a little status report to clear it up. It's also true that many of the topics above aren't really interesting for us, because we just inherit them with CPython, e.g. stdlib changes. Packaging is only relevant as far as it impacts the distribution of binary extensions, and the main changes appear to be outside of that area (which doesn't mean it's not truly wonderful that they are happening, Python packaging has seen a lot of great improvements during the last years and I'm very happy to see it getting even better). Interpreter initialisation would be interesting and Cython could potentially help in some spots here by making code easier to maintain and optimise, for example. We've had this discussion for the importlib bootstrapping and I'm sure there's more that could be done. It's sad to see so much C-level work go into areas that really don't need to be that low-level. I'm not so happy with the argument clinic, but that's certainly also because I'm biased. I've written the argument unpacking code for Cython some years ago, so it's not surprising that I'm quite happy with that and fail to see the need for a totally new DSL *and* a totally new implementation, especially with its mapping to the slowish ParseTuple*() C-API functions. I've also not seen a good argument why the existing Py3 function signatures can't do what the proposed DSL tries to achieve. They'd at least make it clear that the intention is to make things more Python-like, and would at the same time provide the documentation. The topics that would be interesting for us sound more like they'd benefit from a CPython runtime summit. I really think that it would be beneficial for the CPython developers to learn how we solved problems that they have on their lists or might at least run into in a couple of years, and for us to see if we can't come up with cleaner solutions for problems that CPython currently makes hard to do outside of the core. For example, making C-implemented code Python compatible is actually not trivial and has cost us a lot of investment. Nowadays, CPython is actually further away from that in some areas than Cython, and I don't think it needs to stay that way. It could certainly help both Cython and CPython if CPython gained some of the capabilities for itself that we had to implement ourselves in clean or hacky ways, but always outside of the core. There isn't really a reason why C-implemented parts of CPython must behave all that different from Python implemented parts, why modules must have a different API than other objects, why builtins can't accept keyword arguments, ... These things just get in the way once their camouflage as features is blown up. Another topic is C-level calling between extensions that only see each other through the CPython core. Python call semantics are nice, but also extremely slow compared to C calls. Capsules are simple but slow and static. Implementing a dynamic C calling interface between extensions with a safe way to pass C signatures around and validate them (or adapt to them) on the other side would be much easier with CPython support built into its C function type than trying to do this outside of the core. And there's a huge area of applications for such a feature, especially with the increasing number of tools that do dynamic code generation on the CPython platform. Eventually, this might also become interesting for non-CPythons, as it might provide a way to interface efficiently with CPython extensions. So, have fun
Re: [Python-Dev] Python Language Summit at PyCon: Agenda
On Feb 28, 2013, at 08:44 AM, fwierzbi...@gmail.com wrote: Sorry I meant is_jython as a sort of shorthand for a case by case check. It would be cool if we had a nice set of checks somewhere like is_refcounted, etc. Would the sys.implementation area be a good place for such things? Yep. Unless it proves too unwieldy I suppose. On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed through some. This may still need to be checked in that way (there's are still checks of if os.name == 'nt' right?) Yeah, but that all old code ;) -Barry signature.asc Description: 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 Language Summit at PyCon: Agenda
On Fri, Mar 1, 2013 at 4:41 AM, Stefan Behnel stefan...@behnel.de wrote: Michael Foord, 27.02.2013 17:51: PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings Hi, as in the years before, none of the Cython developers is attending the PyCon-US, so we won't appear that the language summit either. It's a bit sad that it always takes place at that venue, but I guess there'll just always be people that can't come to one meeting or the other, so PyCon-US would just catch the majority. I think it would still be interesting for many of the attendants to get a status report about Cython, as there seems to be some confusion and incomplete knowledge about what Cython actually is, what we have achieved and where we are heading. But maybe the confusion is large enough to require more than just a little status report to clear it up. There are actually two language summits each year: PyCon US and EuroPython. But you are right that the US one is the biggest as it's the easiest to get the most core devs in a single room. Hopefully you can make PyCon US (it's a great conference). And if it's a US issue, it will be in Canada in 2014 and 2015. ___ 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 Language Summit at PyCon: Agenda
On Fri, 1 Mar 2013 09:32:23 -0500 Barry Warsaw ba...@python.org wrote: On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed through some. This may still need to be checked in that way (there's are still checks of if os.name == 'nt' right?) Yeah, but that all old code ;) Hmm, what do you mean? `os.name == 'nt'` is still the proper way to test that we're running on a Windows system (more accurately, over the Windows API). 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] Python Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 1:37 PM, Barry Warsaw ba...@python.org wrote: On Feb 27, 2013, at 11:33 AM, fwierzbi...@gmail.com wrote: The easy part for Jython is pushing some of our if is_jython: stuff into the appropriate spots in CPython's Lib/. I wonder if there isn't a better way to do this than sprinkling is_jython, is_pypy, is_ironpython, is_thenextbigthing all over the code base. I have no bright ideas here, but it seems like a feature matrix would be a better way to go than something that assumes a particular Python implementation has a particular feature set (which may change in the future). Yes, avoiding that kind of thing is a key motivation for sys.implementation. Any proposal for is_jython blocks should instead be reformulated as a proposal for new sys.implementation attributes. 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] Python Language Summit at PyCon: Agenda
Le Wed, 27 Feb 2013 11:33:30 -0800, fwierzbi...@gmail.com fwierzbi...@gmail.com a écrit : There are a couple of spots that might be more controversial. For example, Jython has a file Lib/zlib.py that implements zlib in terms of the existing Java support for zlib. I do wonder if such a file is acceptable in CPython's Lib since its 195 lines of code would be entirely skipped by CPython. That's a bit annoying. How will we know that the code still works, even though our buildbots don't exercise it? Also, what happens if the code doesn't work 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] Python Language Summit at PyCon: Agenda
On 28/02/13 07:20, anatoly techtonik wrote: * as an exercise - try to build a scroller for a running Python script * it is impossible for Python 2 and probably for Python 3 as well What do you mean by a scroller? [...] and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0 license If you are correct, that may be a real issue that needs to be resolved. If this issue has been discussed before, can you point me to a previous discussion please? -- 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] Python Language Summit at PyCon: Agenda
On Feb 27, 2013, at 3:20 PM, anatoly techtonik techto...@gmail.com wrote: * security by obscurity in legal position of PSF towards contributors https://code.google.com/legal/individual-cla-v1.0.html vs http://www.python.org/psf/contrib/contrib-form/ + http://www.samurajdata.se/opensource/mirror/licenses/afl-2.1.php or http://www.python.org/psf/contrib/contrib-form/ + http://opensource.org/licenses/apache2.0.php and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0 license I'm not even touching your security through obscurity trollbait, but I'd like to know how the PSF / Python core is non compliant with clause 4, and the legal counsel you spoke to to confirm this. Jesse___ 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 Language Summit at PyCon: Agenda
On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. Michael Georg ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 27 Feb 2013, at 18:50, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 27 Feb 2013 16:51:16 + Michael Foord mich...@voidspace.org.uk wrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. Perhaps someone wants to discuss http://www.python.org/dev/peps/pep-0428/, but I won't be there and the PEP isn't terribly up-to-date either :-) If you can find someone familiar with pathlib to champion the discussion it is more likely to happen and be productive... Getting the PEP up to date before the summit will also help. (I very much like the *idea* of pathlib and the bits I've seen / read through - but I haven't used it in anger yet so I don't feel qualified to champion it myself.) Michael 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
Jesse Noller jnol...@gmail.com wrote: http://www.python.org/psf/contrib/contrib-form/ + http://opensource.org/ licenses/apache2.0.php and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0 license I'm not even touching your security through obscurity trollbait, but I'd like to know how the PSF / Python core is non compliant with clause 4, and the legal counsel you spoke to to confirm this. Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. 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] Python Language Summit at PyCon: Agenda
On 27 Feb 2013, at 19:01, fwierzbi...@gmail.com wrote: On Wed, Feb 27, 2013 at 8:51 AM, Michael Foord mich...@voidspace.org.uk wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. I'd like to discuss merging Jython's standard Lib (the *.py files). We have in the past had agreement that this would be a good idea - I just want to bring it up since I think this is probably the year that I'm actually going to do it. Added to the agenda. Michael -Frank ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On 28 Feb 2013, at 03:42, Barry Warsaw ba...@python.org wrote: On Feb 27, 2013, at 04:51 PM, Michael Foord wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. I'd like to have some discussions around promotion of Python 3, how we can accelerate its adoption, availability of supporting packages, what critical projects are still missing, etc. Added to the agenda. Michael -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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On Feb 28, 2013, at 6:42 AM, Stefan Krah ste...@bytereef.org wrote: Jesse Noller jnol...@gmail.com wrote: http://www.python.org/psf/contrib/contrib-form/ + http://opensource.org/ licenses/apache2.0.php and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0 license I'm not even touching your security through obscurity trollbait, but I'd like to know how the PSF / Python core is non compliant with clause 4, and the legal counsel you spoke to to confirm this. Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.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/jnoller%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] Python Language Summit at PyCon: Agenda
Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. 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] Python Language Summit at PyCon: Agenda
On Feb 28, 2013, at 6:55 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. Regards Antoine. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. ___ 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/jnoller%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] Python Language Summit at PyCon: Agenda
Le Thu, 28 Feb 2013 06:57:36 -0500, Jesse Noller jnol...@gmail.com a écrit : On Feb 28, 2013, at 6:55 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. Regards Antoine. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. Really? I didn't know lawyers flocked at the PSF. It also doesn't provide any public feedback for said resolution, meaning it doesn't help alleviate any future discussions about legal issues. 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] Python Language Summit at PyCon: Agenda
Jesse Noller jnol...@gmail.com wrote: We have one: p...@python.org That's not exactly a public mailing-list. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. If the list isn't publicly archived, the same questions will arise over and over again (probably on python-dev). Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? 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] Python Language Summit at PyCon: Agenda
On Feb 28, 2013, at 7:23 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:57:36 -0500, Jesse Noller jnol...@gmail.com a écrit : On Feb 28, 2013, at 6:55 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. Regards Antoine. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. Really? I didn't know lawyers flocked at the PSF. It also doesn't provide any public feedback for said resolution, meaning it doesn't help alleviate any future discussions about legal issues. Regards Antoine. Yes sir. Ill have a new mailing list made today. I will note on the list page that is is strictly unofficial and all legal / lawyer type things must be sent to p...@python.org for official decisions or legal counsel. ___ 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/jnoller%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] Python Language Summit at PyCon: Agenda
On Feb 28, 2013, at 7:31 AM, Jesse Noller jnol...@gmail.com wrote: On Feb 28, 2013, at 7:23 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:57:36 -0500, Jesse Noller jnol...@gmail.com a écrit : On Feb 28, 2013, at 6:55 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 28 Feb 2013 06:48:24 -0500, Jesse Noller jnol...@gmail.com a écrit : Perhaps it's an idea to have a python-legal mailing list for these topics? I don't think it's fundamentally wrong to scrutinize licenses, provided that the discussion stays civil and factual. IIRC Debian has such a list because people got annoyed with the traffic on other lists. Stefan Krah We have one: p...@python.org That's not exactly a public mailing-list. Regards Antoine. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. Really? I didn't know lawyers flocked at the PSF. It also doesn't provide any public feedback for said resolution, meaning it doesn't help alleviate any future discussions about legal issues. Regards Antoine. Yes sir. Ill have a new mailing list made today. I will note on the list page that is is strictly unofficial and all legal / lawyer type things must be sent to p...@python.org for official decisions or legal counsel. Spent a minute driving to request the new list. Will notify when it's up ___ 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/jnoller%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] Python Language Summit at PyCon: Agenda
Stefan Krah writes: Why would [the PSF list] help to resolve such an issue (if it is an issue at all!) Precisely. If there *is* a compliance problem, there's nothing to be done before talking to the lawyers. Although license *choice* is primarily a political issue, *compliance* is technical. ___ 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 Language Summit at PyCon: Agenda
On Feb 28, 2013, at 8:03 AM, Stephen J. Turnbull step...@xemacs.org wrote: Stefan Krah writes: Why would [the PSF list] help to resolve such an issue (if it is an issue at all!) Precisely. If there *is* a compliance problem, there's nothing to be done before talking to the lawyers. Although license *choice* is primarily a political issue, *compliance* is technical. And the board is legally bound to ensure compliance. I know, I've gotten the email requests clarifying copyright assignments. That being said, I requested a mailing list where this can all be hotly debated and will let everyone know when the playground is open. ___ 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/jnoller%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] Python Language Summit at PyCon: Agenda
On 28/02/13 23:26, Stefan Krah wrote: Jesse Noller jnol...@gmail.com wrote: We have one: p...@python.org That's not exactly a public mailing-list. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. If the list isn't publicly archived, the same questions will arise over and over again (probably on python-dev). Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? Because we can ask somebody on the PSF to commit to replying here with the resolution: - No, we have legal advice that we are not violating the Apache license, and here's why... - Yes, we are violating the license, and this is what we are going to do to fix it... The question of whether or not the PSF is violating the Apache license in some way is not one that is helped by having arbitrary people give their uninformed opinions. I sympathize with curious people wanting to see what's going on, but really, this is not a question to be debated and argued by amateurs and non-lawyers. The PSF has a tame lawyer for exactly these sorts of matters, and we should let him do his job. In any case, until Anatoly replies with details, this counts as nothing more than an unsubstantiated, vague accusation. Over to you Anatoly... -- 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] Python Language Summit at PyCon: Agenda
Le Fri, 01 Mar 2013 00:21:48 +1100, Steven D'Aprano st...@pearwood.info a écrit : The question of whether or not the PSF is violating the Apache license in some way is not one that is helped by having arbitrary people give their uninformed opinions. I sympathize with curious people wanting to see what's going on, but really, this is not a question to be debated and argued by amateurs and non-lawyers. Similarly, programming questions are not to be debated by amateurs and non-programmers. We should just close python-dev. 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] Python Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord fuzzy...@voidspace.org.ukwrote: On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. While Christian is in the best position to discuss this, I did review his various monkeypatch fixes + expat patches so I can attempt to answer any questions people may have. ___ 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 Language Summit at PyCon: Agenda
2013/2/28 Brett Cannon br...@python.org: On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. While Christian is in the best position to discuss this, I did review his various monkeypatch fixes + expat patches so I can attempt to answer any questions people may have. How close are they to being applied? -- 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] Python Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 8:53 AM, Benjamin Peterson benja...@python.orgwrote: 2013/2/28 Brett Cannon br...@python.org: On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 28 Feb 2013, at 07:36, Georg Brandl g.bra...@gmx.net wrote: Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Sure. It would be good if someone who *will* be there can champion the discussion. While Christian is in the best position to discuss this, I did review his various monkeypatch fixes + expat patches so I can attempt to answer any questions people may have. How close are they to being applied? I have no idea. Ask Christian. =) I can just answer what the attacks are and what had to change to protect against them. ___ 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 Language Summit at PyCon: Agenda
On Thursday, February 28, 2013 at 7:26 AM, Stefan Krah wrote: Jesse Noller jnol...@gmail.com (mailto:jnol...@gmail.com) wrote: We have one: p...@python.org (mailto:p...@python.org) That's not exactly a public mailing-list. Nope. But it's also where lawyers flock and these issues can rapidly be resolved. If the list isn't publicly archived, the same questions will arise over and over again (probably on python-dev). Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? See: http://mail.python.org/pipermail/python-dev/2013-February/124463.html ___ 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 Language Summit at PyCon: Agenda
Steven D'Aprano st...@pearwood.info wrote: The question of whether or not the PSF is violating the Apache license in some way is not one that is helped by having arbitrary people give their uninformed opinions. No one will be preventing lawyers from giving their opinions on python-legal. In fact, at least one patent attorney *is* posting on debian-legal. Jesse is right: the list may turn into a playground. In that case, at least the traffic is not on python-dev. 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] Python Language Summit at PyCon: Agenda
Jesse Noller jnol...@gmail.com wrote: Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? See: http://mail.python.org/pipermail/python-dev/2013-February/124463.html That was quick. Thanks! 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] Python Language Summit at PyCon: Agenda
On Thursday, February 28, 2013 at 9:49 AM, Stefan Krah wrote: Jesse Noller jnol...@gmail.com (mailto:jnol...@gmail.com) wrote: Why would it help to resolve such an issue (if it is an issue at all!) for a single person on a private mailing list? See: http://mail.python.org/pipermail/python-dev/2013-February/124463.html That was quick. Thanks! Stefan Krah It only takes a minute or two to do something good. Now how about dem XML vulnerabilities? ;) ___ 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 Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 7:37 PM, Barry Warsaw ba...@python.org wrote: On Feb 27, 2013, at 11:33 AM, fwierzbi...@gmail.com wrote: I am suggesting that we push forward on the shared library approach to the files in the Lib/* directory, so that would certainly include IronPython and PyPy as well I hope. +1 The easy part for Jython is pushing some of our if is_jython: stuff into the appropriate spots in CPython's Lib/. I wonder if there isn't a better way to do this than sprinkling is_jython, is_pypy, is_ironpython, is_thenextbigthing all over the code base. I have no bright ideas here, but it seems like a feature matrix would be a better way to go than something that assumes a particular Python implementation has a particular feature set (which may change in the future). Sorry I meant is_jython as a sort of shorthand for a case by case check. It would be cool if we had a nice set of checks somewhere like is_refcounted, etc. Would the sys.implementation area be a good place for such things? On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed through some. This may still need to be checked in that way (there's are still checks of if os.name == 'nt' right?) -Frank ___ 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 Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 1:15 AM, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Feb 28, 2013 at 1:37 PM, Barry Warsaw ba...@python.org wrote: On Feb 27, 2013, at 11:33 AM, fwierzbi...@gmail.com wrote: The easy part for Jython is pushing some of our if is_jython: stuff into the appropriate spots in CPython's Lib/. I wonder if there isn't a better way to do this than sprinkling is_jython, is_pypy, is_ironpython, is_thenextbigthing all over the code base. I have no bright ideas here, but it seems like a feature matrix would be a better way to go than something that assumes a particular Python implementation has a particular feature set (which may change in the future). Yes, avoiding that kind of thing is a key motivation for sys.implementation. Any proposal for is_jython blocks should instead be reformulated as a proposal for new sys.implementation attributes. Ah nice - the merging effort should definitely cause some careful consideration of these. Maybe I'll start a discussion about a garbage collection type for sys.implementation. Some way to ask gc != refcounted would catch some of these. -Frank ___ 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 Language Summit at PyCon: Agenda
On Thu, Feb 28, 2013 at 1:30 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Wed, 27 Feb 2013 11:33:30 -0800, fwierzbi...@gmail.com fwierzbi...@gmail.com a écrit : There are a couple of spots that might be more controversial. For example, Jython has a file Lib/zlib.py that implements zlib in terms of the existing Java support for zlib. I do wonder if such a file is acceptable in CPython's Lib since its 195 lines of code would be entirely skipped by CPython. That's a bit annoying. How will we know that the code still works, even though our buildbots don't exercise it? Also, what happens if the code doesn't work anymore? That is definitely something to think about. Maybe when this becomes a serious effort and not just talk I can help get a Jython buildbot going. -Frank ___ 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 Language Summit at PyCon: Agenda
On Feb 27, 2013, at 11:51 AM, Michael Foord wrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) Since the time I suggested we add packaging to the agenda, Nick has set up a separate summit meeting for Friday evening. I don't know if it makes sense to leave this on the agenda for Wednesday or not. Nick, what do you think? Doug * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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/doug.hellmann%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] Python Language Summit at PyCon: Agenda
Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 10:51 AM, Michael Foord mich...@voidspace.org.uk wrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. I'll take detailed notes again this year. Within a few days of the end of the conference I'll post a write-up to blog.python.org and this list to keep everyone informed. ___ 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 Language Summit at PyCon: Agenda
On Wed, 27 Feb 2013 16:51:16 + Michael Foord mich...@voidspace.org.uk wrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. Perhaps someone wants to discuss http://www.python.org/dev/peps/pep-0428/, but I won't be there and the PEP isn't terribly up-to-date either :-) 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] Python Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 8:51 AM, Michael Foord mich...@voidspace.org.uk wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. I'd like to discuss merging Jython's standard Lib (the *.py files). We have in the past had agreement that this would be a good idea - I just want to bring it up since I think this is probably the year that I'm actually going to do it. -Frank ___ 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 Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 2:01 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Wed, Feb 27, 2013 at 8:51 AM, Michael Foord mich...@voidspace.org.uk wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. I'd like to discuss merging Jython's standard Lib (the *.py files). We have in the past had agreement that this would be a good idea - I just want to bring it up since I think this is probably the year that I'm actually going to do it. Do you mean more generally getting more pure Python implementations of modules in the stdlib? If so then as a reference there is http://bugs.python.org/issue16651 which lists the modules in the stdlib w/ only extension module implementations (although operator and random have patches; the latter is waiting for Raymond to approve). And if I am right about what you are suggesting, Frank, this should probably be expanded to a more concerted effort with IronPython and PyPy. IOW it warrants a discussion. =) ___ 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 Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 11:21 AM, Brett Cannon br...@python.org wrote: Do you mean more generally getting more pure Python implementations of modules in the stdlib? If so then as a reference there is http://bugs.python.org/issue16651 which lists the modules in the stdlib w/ only extension module implementations (although operator and random have patches; the latter is waiting for Raymond to approve). That is part of it, although my bigger goal is slightly more ambitious. I'm hoping to eventually delete the entire Lib/ directory from Jython and just pull in CPython's. And if I am right about what you are suggesting, Frank, this should probably be expanded to a more concerted effort with IronPython and PyPy. IOW it warrants a discussion. =) Oh sure sorry - I have some tunnel vision lately :) I am suggesting that we push forward on the shared library approach to the files in the Lib/* directory, so that would certainly include IronPython and PyPy as well I hope. The easy part for Jython is pushing some of our if is_jython: stuff into the appropriate spots in CPython's Lib/. I'd also like to do something at the top of CPython specific .py files that would fail the import in case it is called from Jython. I suspect that OS packagers would like it if the Lib directory for a particular Python version could be entirely shared between implementations. There are a couple of spots that might be more controversial. For example, Jython has a file Lib/zlib.py that implements zlib in terms of the existing Java support for zlib. I do wonder if such a file is acceptable in CPython's Lib since its 195 lines of code would be entirely skipped by CPython. Anyway I think I might be rambling - it seems like a good thing to discuss :) -Frank ___ 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 Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 7:51 PM, Michael Foord mich...@voidspace.org.ukwrote: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. I won't be able to visit, so this PyCon promises to be all good nice and relaxing for everybody. =) But here is some things that can spice up the meeting in case it becomes boring. * poor introspection capabilities * if you pause the code - what kind of data you'd like to be available? * magical locals() dict that breaks the rules * execution frames that lose information present in original source (such as function vs method and probably others) * as an exercise - try to build a scroller for a running Python script * it is impossible for Python 2 and probably for Python 3 as well * visibility issues with language development * physically split the information flow about work being done on interpreter and stdlib * split the information about stdlib development by modules * describe modules composing in stdlib in formal way https://bitbucket.org/techtonik/python-stdlib * build a roadmap by module (join personal wishlist from involved people) * external people can not join teams dedicated only to several modules people are interested in * IPython and PyPy as a distraction for people who could improve core language and stdlib here * security by obscurity in legal position of PSF towards contributors https://code.google.com/legal/individual-cla-v1.0.html vs http://www.python.org/psf/contrib/contrib-form/ + http://www.samurajdata.se/opensource/mirror/licenses/afl-2.1.php or http://www.python.org/psf/contrib/contrib-form/ + http://opensource.org/licenses/apache2.0.php and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0 license * how to get more pictures and less text for reference, especially for internals * user story approach for writing PEPs Can only wish to have a constructive PyCon with great results. Bye. -- anatoly t. ___ 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 Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 12:33 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: There are a couple of spots that might be more controversial. For example, Jython has a file Lib/zlib.py that implements zlib in terms of the existing Java support for zlib. I do wonder if such a file is acceptable in CPython's Lib since its 195 lines of code would be entirely skipped by CPython. Even if it's pure Python, that sounds like an accelerator module (a la PEP 399) to me. -eric ___ 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 Language Summit at PyCon: Agenda
On Feb 27, 2013, at 11:33 AM, fwierzbi...@gmail.com wrote: I am suggesting that we push forward on the shared library approach to the files in the Lib/* directory, so that would certainly include IronPython and PyPy as well I hope. +1 The easy part for Jython is pushing some of our if is_jython: stuff into the appropriate spots in CPython's Lib/. I wonder if there isn't a better way to do this than sprinkling is_jython, is_pypy, is_ironpython, is_thenextbigthing all over the code base. I have no bright ideas here, but it seems like a feature matrix would be a better way to go than something that assumes a particular Python implementation has a particular feature set (which may change in the future). -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] Python Language Summit at PyCon: Agenda
On Feb 27, 2013, at 04:51 PM, Michael Foord wrote: If you have other items you'd like to discuss please let me know and I can add them to the agenda. I'd like to have some discussions around promotion of Python 3, how we can accelerate its adoption, availability of supporting packages, what critical projects are still missing, etc. -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] Python Language Summit at PyCon: Agenda
Am 27.02.2013 17:51, schrieb Michael Foord: Hello all, PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so. The agenda of topics for discussion so far includes the following: * A report on pypy status - Maciej and Armin * Jython and IronPython status reports - Dino / Frank * Packaging (Doug Hellmann and Monty Taylor at least) * Cleaning up interpreter initialisation (both in hopes of finding areas to rationalise and hence speed things up, as well as making things more embedding friendly). Nick Coghlan * Adding new async capabilities to the standard library (Guido) * cffi and the standard library - Maciej * flufl.enum and the standard library - Barry Warsaw * The argument clinic - Larry Hastings If you have other items you'd like to discuss please let me know and I can add them to the agenda. May I in absentia propose at least a short discussion of the XML fixes and accompanying security releases? FWIW, for 3.2 and 3.3 I have no objections to secure-by-default. Georg ___ 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
