Mailman 3 April 2009 - Python-Dev

3.1a2
by Benjamin Peterson 02 Apr '09

02 Apr '09

Hi, I'd like to release the second alpha of 3.1 as planned on Saturday, April 4th. There are currently two release blockers, issues #4847 and #5470. #5470 appears to be Martin's issue. I haven't looked at #4847 in depth, but appears that the csv module will need some API changes to deal with encodings. Perhaps somebody would like to sprint on it? -- Regards, Benjamin

6 14

splitting out bdist_* (was: interminable 'setuptools' thread)
by glyph＠divmod.com 01 Apr '09

01 Apr '09

On 07:59 pm, fdrake(a)acm.org wrote: >I'm actually in favor of removing the bdist_* from the standard >library, and allowing 3rd-party tools to implement whatever they need >for the distros. But I don't think what you're presenting there >supports it. I do think that it's relevant that the respective operating system packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not very useful to have a bdist_deb that nobody actually builds debs with. This has been a problem for me, personally, since debian has made various ad-hoc change to Twisted or Twisted-based packages to break our plugin system, since the distutils metadata has been insufficient for their purposes. If the deb-generating stuff were in a separate project with a faster release cycle that were easier to contribute packages to, perhaps debian packagers could be convinced to contribute their build- hacks there (and bdist_deb could invoke debhelper, or vice-versa). It would be great if someone could volunteer to maintain this stuff independently, put it in a Launchpad project or something. IMHO it would be better for the community at large if this were spun as "increasing the release speed" of the bdist_* family, rather than "removing", which seems to me like it would generate another teacup- tempest on the blogowebs. Of course I'm not volunteering, but I will be best friends forever with whoever does this PR/maintenance :). Given that py2exe and py2app (which includes "bdist_mpkg") are both based on distutils, it seems like we're on the way to independent maintenance anyway. Perhaps bdist_wininst/_msi could be donated to the py2exe project if they would be willing to maintain it, and the new project for _deb and _rpm could be called "py2packman" or something.

12 14

bdb.py trace C implementation?
by David Christian 01 Apr '09

01 Apr '09

Hi all, I've recently written a C version of the trace function used in figleaf (the coverage tool written by Titus). After a few rewrites to add in caching, etc, it gives users a significant speedup. One person stated that switching to the C version caused coverage to decrease from a 442% slowdown to only a 56% slowdown. You can see my C implementation at: http://github.com/ctb/figleaf/blob/e077155956c288b68704b09889ebcd675ba02240… (Specific comments about the implementation welcome off-list). I'd like to attempt something similar for bdb.py (only for the trace function). A naive C trace function which duplicated the current python function should speed up bdb significantly. I would initially write the smallest part of the C implementation that I could. Basically the tracing function would call back out to python at any point where a line requires action. I'd be willing to maintain the C implementation. I would be willing to write those tests that are possible as well. Is this something that would be likely to be accepted? Thanks, David Christian Senior Software Engineer rPath, Inc.

4 6

Wing IDE and python.wpr
by Michael Foord 01 Apr '09

01 Apr '09

Hello all, How many are using the Wing IDE to work on core Python? It would be nice to have a 'python.wpr' checked in to trunk, as I have to recreate the project file every time I do a new checkout. Would this be useful for anyone else? Where is a good place for it to live? Littering the top level directory seems like a bad idea but I can't see anywhere else immediately *obvious* (no reason it has to live at the top level). Wing can be configured to use two files for the project - one file for the basic configuration (which would be checked in) and one for your personal settings (which files you have open, how many windows you are using etc) and would be svn-ignored. Michael Foord -- http://www.ironpythoninaction.com/

1 1

Python 2.6 64-bit Mac Release
by Peck, Jon 01 Apr '09

01 Apr '09

Apparently the Mac Python 2.6.1 Installer image does not include 64-bit binaries. Is this going to change? Is there some technical reason why these are not included? We are hoping to support that in our next 64-bit release. Thanks for your help. Jon K. Peck SPSS Inc. peck(a)spss.com (ip) phone 312-651-3435

3 2

All Hail the FLUFL
by Frank The Extruder Lomax 01 Apr '09

01 Apr '09

On behalf of the entire Python community and as CTO of Cheez Whiz Global Conglomerates, Inc. I would like to extend My Thanks to our BDEVIL's many Selfless and Dedicated years of service. I can say without remorse that the State of the Art in the Gas Propelled Cheezical Sciences would be 11 years behind schedule if it weren't for the BDEVIL and Python. However, as we at CWGC have been Contemplating an upgrade to our Pythonic Orange Oscillation Process for many years - we're still on Python 1.5.1 and due to our Centuries-Old corporate culture, only upgrade to multiples of two - we have been dismayed by recent Unfortunate Decisions negatively impacting our hope of world-wide long term acceptance of Python 3.0.2. Thus I applaud you for your chosen New Path, wish you a Speedy Shirpa Assisted Ascent, and I welcome our new FLUFL's similarly Lofty Ascent to Pythonic Overlordhood. You may not realize that the technology behind our groundbreaking Subsonic Plasticine Extrusion of Coagulated Flavor Oil utilize inequalities to a vast degree. In fact, our many Published Papers confirm our mathematical leadership in the Algebraic States of Less Than and More Than Simultaneity. Were it not for the Diamond Operator, billions, nay! trillions of crackers would have languished Unadorned, Unenjoyed, and Unloved. For this reason, the sole choice of the Evil Hash-Equal was enough to force us to Seriously Investigate a switch to Stenographic Non-deterministic SQL (a promising new scripting language somewhat similar to Ruby). It is with an Overboiling Pot of Joy that we fully support Official FLUFL Act 2. Trust me when I say that with this single reversion, the world of High Velocity Extremely High Pressure Milkyish Orange Goop Delivery Devices will never be the same. I am also Ecstatic at the reversal of DVCS decision. It is with no Small Irony that I admit the mere utterance of any derivative of the root word "Mercury" is a firing offence in my Establishment. In honor of our new FLUFL, I am directing our CFO Timmy "The Larch" Lomax (no direct relation to myself) to donate the sum of USA $23,250 to the PSU in furtherance of their mission. If there is a PyCon sponsorship level Above Diamond (may we suggest "Orange"?) we would be honored to claim that Pinnacle for 2010. Atlanta is located very near our Secret Manufacturing Facility and I would be remiss if I did not direct additional PyCon branded delivery of 5000 cans of our Premium Velvet Brand Cheez Whiz Lunchables with Detachable Shooters. I think the 2010 conference attendees will appreciate the diversion and hope this will entice people to join our Sprint next year. foolish-ly y'rs, frank

1 0

Re: [Python-Dev] Broken import?
by Guido van Rossum 01 Apr '09

01 Apr '09

[Adding python-dev. I'm quoting the entire original message.] > On Thu, Mar 19, 2009 at 6:40 PM, Fredrik Lundh <fredriklundh(a)google.com> wrote: >> PS. Is it just me, or is import broken in 3.0? Consider this: >> >> $ more package\a.py >> print("in a") >> >> import b >> >> def a(): >> print("here") >> >> def main(): >> b.b() >> >> $ more package\b.py >> print("in b") >> >> import a >> >> def b(): >> a.a() >> >> Under 2.X, this prints "in a" "in b" and "here", as expected. Under >> 3.0, using the "from . import" form for relative imports, it bombs out >> with a: >> >> in a >> in b >> Traceback (most recent call last): >> File "main.py", line 1, in <module> >> from package import a >> File "package/a.py", line 3, in <module> >> from . import b >> File "package\b.py", line 3, in <module> >> from . import a >> ImportError: cannot import name a >> >> Sure, it's a recursive import, but there's no recursive dependency >> here - nobody will access the module contents until the main program >> calls the library. What am I missing? On Mon, Mar 30, 2009 at 5:44 PM, Guido van Rossum <guido(a)python.org> wrote: > I reproduced this, but it seems to have more to do with "from . import > ..." than with the Python version. If I add the "from ." before each > of the imports, "python -c 'import p.a' " fails with roughly the above > traceback for any version of Python that supports this syntax, while > without that it passes for any 2.x. > > If I use the "from ." syntax in a.py but not in b.py, "import p.a" > passes but "import p.b" fails. > > I'll see if anyone present at the sprints has a clue. Made some progress. Anything using "from <whatever> import b" (where <whatever> is either '.' or 'p') will fail when b's import is not completed. OTOH using "import p.b" works. I reduced it to: p/a.py == "from p import b" p/b.py == "import a" python -c "import p.b" The reason seems to be that until the outermost import (in this case p.b) is completed, while sys.modules has the (incomplete) modules 'p', 'p.a' and 'p.b', the attributes p.a and p.b aren't added until after their import is completed. Which it isn't during recursive import. Apparently 'from <anything> import <something>' looks for the <something> attribute in the <parent> object. This is because "from...import" can also be used to import objects other than modules (e.g. "from M import C"). I'm guessing that setting the attribute is delayed until the import is totally complete, because upon a failed import we remove the half-imported module object from sys.modules, but apparently we didn 't want to be in the business of removing the attribute from the parent package, so that's only set after the import is deemed successful. At least, this is my hypothesis, thinking about it -- I might look at the code later. :-) The most portable solution is to avoid "from...import" and instead write something like import p.b as b -- --Guido van Rossum (home page: http://www.python.org/~guido/)

4 9

Test failures under Windows?
by Antoine Pitrou 01 Apr '09

01 Apr '09

Hello, I've just tried running test_io under Windows (in a virtual machine) and I get the following failures: ====================================================================== ERROR: test_error_through_destructor (test.test_io.CTextIOWrapperTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Z:\py3k\__svn__\lib\test\test_io.py", line 1543, in test_error_through_d estructor self.assertRaises(AttributeError, f) File "Z:\py3k\__svn__\lib\unittest.py", line 457, in failUnlessRaises callableObj(*args, **kwargs) File "Z:\py3k\__svn__\lib\test\test_io.py", line 1541, in f self.TextIOWrapper(rawio).xyzzy OSError: [Errno 9] Bad file descriptor ====================================================================== ERROR: test_error_through_destructor (test.test_io.PyTextIOWrapperTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Z:\py3k\__svn__\lib\test\test_io.py", line 1543, in test_error_through_d estructor self.assertRaises(AttributeError, f) File "Z:\py3k\__svn__\lib\unittest.py", line 457, in failUnlessRaises callableObj(*args, **kwargs) File "Z:\py3k\__svn__\lib\test\test_io.py", line 1541, in f self.TextIOWrapper(rawio).xyzzy File "Z:\py3k\__svn__\lib\_pyio.py", line 1356, in __init__ encoding = os.device_encoding(buffer.fileno()) OSError: [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Am I the only one getting those? By the way, what happened to the Windows buildbots? Regards Antoine.

10 34