Mailman 3 March 2009 - Python-Dev

This seems like a bug - main thread has None ident???
by skip＠pobox.com 31 Mar '09

31 Mar '09

Looking for some quick feedback on this. I've bumped into what looks like a bug in the threading module. From the interpreter prompt: >>> import threading >>> threading.currentThread() <_MainThread(MainThread, started)> >>> print threading.currentThread().ident None The ident attribute is documented as being a number unless the thread has yet to be started. Shouldn't the main thread's ident attribute *always* be non-None? Clearly, it appears the main thread has been started. Am I missing something obvious or have I hit a bug? This is a fully updated 2.7a0 build, trunk:70878M. Skip

1 0

regrtest behavior change
by R. David Murray 31 Mar '09

31 Mar '09

At the sprint the developers decided that a long standing issue with regrtest should be fixed: the fact that invalid imports in tests can result in a test being skipped instead of producing an error. I've just checked in a change to regrtest on the trunk. It no longer assumes that an ImportError means the test should be marked as skipped. I have done my best to wrap all imports where errors _should_ cause skips in the appropriate wrappers from test_support (import_module or get_attribute). Of course, since I can't run the tests on all possible systems I may have missed some. It's also possible that making this change will unmask some errors that have been hidden by the previous behavior, although I haven't found any instances of that so far. Another issue is that there may be modules that don't exist on other VM implementations where those modules would have been skipped on a test run previous to this, and will now generate an ImportError. We will happily wrap imports for those modules when informed that such should be done. I'll be watching the buildbots, but please let me know about any issues that you find. I'll be merging it to py3k as well, but there will be no backport. -- R. David Murray http://www.bitdance.com

1 0

And the winner is...
by Guido van Rossum 31 Mar '09

31 Mar '09

Dear Python developers, The decision is made! I've selected a DVCS to use for Python. We're switching to Mercurial (Hg). The implementation and schedule is still up in the air -- I am hoping that we can switch before the summer. It's hard to explain my reasons for choosing -- like most language decisions (especially the difficult ones) it's mostly a matter of gut feelings. One thing I know is that it's better to decide now than to spend another year discussing the pros and cons. All that could be said has been said, pretty much, and my mind is made up. To me, the advantages of using *some* DVCS are obvious. At PyCon, Brett already announced that Git was no longer being considered -- while it has obviously many fans, it also provokes strong antipathies. So it was between Hg and Bzr (both of which happen to be implemented in Python FWIW). Based on a completely unscientific poll (basically whatever feedback I received in my personal inbox or on Twitter), Hg has a strong following among Python developers and few detractors, while few (except Canonical employees) seem to like Bzr. In addition, most timing experiments point towards Hg being faster than Bzr for most operations, and Hg is (again, subjectively) easier to learn for SVN users than Bzr. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

5 6

Re: [Python-Dev] [Python-ideas] CapPython's use of unbound methods
by Guido van Rossum 31 Mar '09

31 Mar '09

[Adding back python-dev, I don't want this discussion fragmented.] Denis, I am arguing with Mark because he and others claim that it is possible to add capabilities to Python *without* changing the flavor of the language (much), and because he believes that using a subset of Python is somehow helpful for Python programmers (or helps Python programmers transitioning to CapPython). I'm trying to point out the limitations of that approach. In the past capability zealots have also requested forcefully that Python should support capabilities natively. This sounds like an unrealistic evolutionary path for the language, and I'm pointing that out. (Certainly I don't see CapPython as a step in that direction -- perhaps Tav's approach could be.) If they are happy with a different language that happens to resemble Python is some syntactic details that would be fine of course, but then they shouldn't whine that Py3k breaks their implementation. I also suspect that Mark's approach might be easily crackable because he doesn't know the CPython implementation well enough to be aware of all possible attack vectors. --Guido On Tue, Mar 31, 2009 at 4:22 AM, spir <denis.spir(a)free.fr> wrote: > Le Mon, 30 Mar 2009 16:19:51 -0500, > Guido van Rossum <guido(a)python.org> s'exprima ainsi: > > [...] >> > Fortunately CapPython does not have to make this kind of semantic >> > change. >> >> Well of course it makes a much more severe semantic change by >> declaring illegal all use of attribute names starting with underscore. > [...] > > Hello, > > I wonder what's the meaning of this exchange. As I understand it, the point of CapPython is precisely to build a different dialect which semantic field is restricted, in order to comply with the so-called "Object-Capability" security guidelines. > We may like it or not. So what? I won't use CapPython, but I'm pleased to see people do language experiments on a Python basis. > Now, I also understand this: if ever for you CapPython breaks fondamental design choices, then you may not like, as Python inventor, this projects to be called *Python. I would even agree, from a moral point of view, with a demand for a name change. > > (Sorry if this sounds a bit rude. Not sure of idiom connotations in english. I prefere clarity to hypocrisy.) > > Denis > > PS: I had a kind of ProtoPython in mind. If ever someone comments that it's a major semantic change; that it does not let pythonistas use their beloved class-ic idioms; then I'll just laugh... Yes, it's even a major cognitive change. This is precisely the intent. So what? > > ------ > la vita e estrany > -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

CMake Evaluation
by Bill Hoffman 31 Mar '09

31 Mar '09

Hi, I noticed the thread on CMake evaluation, and as a CMake developer I am interested in helping you evaluate CMake. I guess four issues were raised: >A. It has no equivalent of autoheader, so we'd have to maintain pyconfig.h.in by hand. This is currently true, but if this were a deal breaker, I am sure something could be added to CMake to accommodate the need. It might even be possible to create a CMake function that does something like this without having to modify CMake itself. >B. It does not allow the CMakeLists.txt file control the --help output. This appears to be an intentional decision (http://www.cmake.org/pipermail/cmake-promote/2006-May/000095.html). To replace it, they have an interactive mode (which asks you about each possible option) and a -LH flag (which runs the whole configure process and then tells you about the flags you could have set if you knew about them). CMake now has a cmake-gui (qt based application) for configuring a project. C. It does not allow the CMakeLists.txt file to see the command line, so we can't stay backward compatible with the configure script, and we'd have to replace flags like --with-pydebug with -Dpydebug:bool=true. We could write a separate configure script to mitigate this and the previous problem, but we'd have to keep that in sync with CMakeLists.txt manually. We have talked about adding this to CMake several times, and it is a good idea. However, it has not been a huge issue for many projects. D. It doesn't have an expression language, so to replace ac_md_system=`echo $ac_sys_system | tr -d '[/ ]' | tr '[[A-Z]]' '[[a-z]]'` you have to write: string(REGEX REPLACE "[/ ]" "" ac_md_system ${ac_sys_system}) string(TOLOWER ${ac_md_system} ac_md_system) However, the above CMake script will work on any platform with CMake installed, and does not use tr. Also, the CMake code for the above should actually run faster as it is not running two processes with pipe communication. I would not think that this list of issues would be a deal breaker. The benefits of CMake are a single build system that works cross platform. Developers can use the native tools that they are used to using (VS IDE, Xcode IDE, Eclipse IDE, nmake command line, gmake command line, etc.). The original Python CMake work done by Alex, was done to support the building of ParaView (www.paraview.org) on a Cray Xt5 computer using CMake's cross-compilation support. This worked very well. The choice is obviously yours to make, but if you have any specific questions about CMake, I will lurk on this mailing list and try to answer them. I think it would be a good fit for CMake to build Python, and make things easier for some of our customers building ParaView which depends on Python on machines like the Cray Xt5. Thanks. -Bill

3 2

Python 3.0.2
by Barry Warsaw 30 Mar '09

30 Mar '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We made a decision at the sprints today about Python 3.0. We've agreed that there will be one more release, 3.0.2 and then that's it. Because of the earlier decision to drop all support for Python 3.0 once 3.1 is released, we won't be doing any more releases after that. I don't have an ETA for 3.0.2, but I'm happy to do it whenever it makes sense. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdEMYXEjvBPtnXfVAQLNLQP/XY9Wv3QvoqvEhgberz45inXqMpiMuhAL knw+tjtpwtizim4yXFR4EQxa0OhsAgqMPCe+m4CDTGSqcasQAa5iRkk5He5h0Z2C gBP3/DxfECb84r1aDuP4t1wCjqPmNq2T7kIiB7rTRTZktma/1vL2NH3zA4AErQnf b/wjc4zIExg= =kbT0 -----END PGP SIGNATURE-----

3 3

Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
by P.J. Eby 30 Mar '09

30 Mar '09

At 10:39 PM 3/26/2009 -0500, Guido van Rossum wrote: >That +0 could turn into a +1 if there was a way to flag this as an >error (at runtime), at least if the return is actually executed: > >def g(): > yield 42 > return 43 > >for x in g(): > print x # probably expected to print 42 and then 43 > >Perhaps the exception used in this case could be a different exception >than StopIteration? Regular iteration could either just pass this >exception through or explicitly check for it (a single pointer >comparison could usually suffice), depending on whether it would be a >subclass of StopIteration. Could we at least have some syntax like 'return from yield with 43', to distinguish it from a regular return, clarify that it's returning a value to a yield-from statement, and emphasize that you need a yield-from to call it? If it doesn't have some sort of variant syntax, the error message for the return exception is going to need to be rather verbose in order to be clear. However, if there is a variant syntax, then an error message like "'return from yield' without 'yield from'" might be clear enough, and we can keep the current error for returning values in generators. That way, the paired special syntax is clearly identifiable as coroutine/microthread control flow, in a way that's both TOOOWTDI and EIBTI. One remaining quirk or missing piece: ISTM there needs to be a way to extract the return value without using a yield-from statement. I mean, you could write a utility function like: def unyield(geniter): try: while 1: geniter.next() except GeneratorReturn as v: return v.value OTOH, I suppose this function is still a trampoline, just one that doesn't actually do anything except return an eventual exit value. I suppose you could do a slightly improved one thus: def unyield(geniter, value=None, func=lambda v: v) try: while 1: value=func(geniter.send(value)) except GeneratorReturn as v: return v.value And drop it into itertools or some such. It's sort of like an all-purpose map/reduce for generators, so that all you need to do is pass in a function to do whatever processing you need (e.g. I/O waiting) on the values yielded. You could also use another generator's send() method as the function passed in, in which case you'd basically have a pair of coroutines... and whichever returned a value first would end up as the return value of the overall function. That'd probably be pretty useful for the sort of simple (non I/O) coroutines Greg seems to have in mind. Or, these could just be examples in the PEP, I suppose. They're not terribly difficult to write... but then I might be biased since I've written a ridiculous number of coroutine trampolines for Python generators over the last how-many-ever years Python has had generators.

5 6

¿Nueva reunión mensual en Madrid?
by Jesus Cea 30 Mar '09

30 Mar '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Va tocando hacer una nueva reunión mensual en Madrid. ¿Propuestas de fecha y lugar?. La última vez estuvo bastante bien, aunque éramos poquitos. ¿Hacemos otra a la vuelta de semana santa?. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSdD3x5lgi5GaxT1NAQI0PgQAoPtOHTNfc5HOqj6YhChWalVt7JHidouh v779NvzJ4BxepT/g6bs0N59twUX0zkodiRshc/9Hc4zKpXzTFJ3ku4f8yg2KFfL0 jH7A4EvRHrr2xWlcbYtB4qeorPhdRnsuuxfAX09LRdjD9m5VxGso/nVBSt0N5BMd nni9xP72/gM= =oInB -----END PGP SIGNATURE-----

1 1

Re: [Python-Dev] My summit notes (packaging)
by P.J. Eby 30 Mar '09

30 Mar '09

At 03:06 PM 3/27/2009 -0500, Tarek Ziadé wrote: > They both aim at the > same goal besides a few differences, and they both rely > on a new metadata introduced by setuptools, wich is. > "install_requires". This new metadata extends the metadata. > described in PEP 314 but is slightly different from. > what is descibred in the Draft PEP 345 ("Requires"). >.. > PEP 345 introduces "Requires" and "Provides" wich are > are implemented in Distutils and PyP, but are not > widely used. 40 out of +4000 if I remember correctly. Martin will > correct me here if I am wrong. FYI, The reason setuptools uses a different way of specifying requirements is that the PEP-proposed way could not be used without some kind of indexed repository of packages -- and PyPI did not index "provides" at the time. Also, the PEP-proposed versioning scheme was not compatible with the versioning schemes actually used in the field at the time. These conditions could be considered to have changed now, or be changeable given enough will and volunteer effort. Since setuptools was only a 1.5-person effort back in the day (i.e., me plus occasional contribs from Ian Bicking, Bob Ippolito, and Jim Fulton), and backward compatibility was a critical requirement to get adoption, using RPM-style provides/requires was not an option at that time. > - there should be an API to get metadata for a package without > actually executing any of the package's installation script. Please note that where dependencies are concerned, practical considerations require that, at least for currently-released versions of Python, a package's dependencies may well be Python-version specific. A library that targets Python 2.4 and 2.5 and uses wsgiref, sqlite, ctypes, or ElementTree, for example, may have different dependencies depending on the version it is being installed in. Of course, if future Python versions declare metadata for what they include, this could be resolved. But for existing versions it's a bit of a sticky issue. Also, it's quite likely that platform-specific dependencies may exist as well. It might be possible to accommodate these things with a sufficiently flexible format, but currently, the only way to handle them with distutils/setuptools is in the setup script.

5 4

Re: [Python-Dev] "setuptools has divided the Python community"
by P.J. Eby 30 Mar '09

30 Mar '09

At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote: >2009/3/26 Barry Warsaw <barry(a)python.org>: > > BTW, under a better name, I would support putting pkg_resources in the > > stdlib. > >Last time I looked it was an incredibly complicated piece of code that >would have to be refactored considerably before it would be >maintainable by the core developers. I never did manage to get a good >understanding of the code, but I expect that a lot of the complexity >exists so that it works for all Python versions. The stdlib version >shouldn't need this -- it should only care about providing a stable >API that works with the current version. As someone else suggested, moving some of the functionality to PEP 302 interfaces would also help. Most of the code, though, deals with locating/inspecting installed distributions, resolving version requirements, and managing sys.path. And most of the nastiest complexity comes from trying to support true filename access to resources -- if that were dropped from the stdlib, there'd be no need for egg caches and the like, along with all the complexity entailed. Application environments such as Chandler, Trac, Zope, etc. that want their plugins to live in .egg files wouldn't necessarily be able to use such an API, but the independent pkg_resources wouldn't be disappearing. (Of course, they could also implement application-specific file extraction, if the stdlib API included the ability to inspect and open zipped resources.) The other significant source of complexity is dynamic management of namespace packages; specifically, trying to handle the situation where new sys.path entries (e.g. .egg files added as plugins) need to have their contents added to existing sys.modules __path__ entries. This is perhaps another feature that could be dropped from the stdlib version, given a way to interop with pkg_resources or a replacement.

16 38