Mailman 3 March 2009 - Python-Dev

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
by Jim Jewett April 5, 2009

April 5, 2009

Michael Foord wrote: > Chris Withers wrote: >> ... love to see ... but ... not optimistic >> - python to grow a decent, cross platform, package management system As stated, this may be impossible, because of the difference in what a package should mean on Windows vs Unix. If you just mean a way to add python packages from pypi as with EasyInstall, then maybe. >> - the standard library to actually shrink to a point where only >> libraries that are not released elsewhere are included In some environments, each new component must be approved. Once python is approved, the standard library is OK, but adding 7 packages from pypi requires 7 more sets of approvals. On the other hand, if there were a way to say "The PSF explicitly endorses Packages X, Y, and Z as worthy of the stdlib; they are distributed separately for administrative reasons", then the initial request could be for "Python plus officially endorsed addons" That said, it may make sense to just give greater prominence to existing repackagers, such as ActiveState or Enthought. > If a library is well maintained then there seems to be little point in > moving it into the standard library The official endorsement is in many cases more important than shared distribution. -jJ

37 134

Re: [Python-Dev] [Distutils] unicode bug in distutils
by Phillip J. Eby April 5, 2009

April 5, 2009

At 02:47 PM 2/24/2007 -0600, Tarek Ziadé wrote: >I have created a setup.py file for distirbution and I bumped into >a small bug when i tried to set my name in the contact field (Tarek Ziadé) > >Using string (utf8 file): > >setup( > maintainer="Tarek Ziadé" >) > >leads to: > > File ".../lib/python2.5/distutils/command/register.py", line 162, in > send_metadata > auth) > File ".../lib/python2.5/distutils/command/register.py", line 257, in > post_to_server > value = unicode(value).encode("utf-8") >UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 10: >ordinal not in range(128) > > >Using unicode: > >setup( > maintainer=u"Tarek Ziadé" >) > >leads to: > > File ".../lib/python2.5/distutils/dist.py", line 1094, in write_pkg_file > file.write('Author: %s\n' % self.get_contact() ) >UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in >position 18: ordinal not in range(128) > >I would propose a patch for this problem but i don't know what would be >the best input (i guess unicode > for names) At 05:45 PM 2/24/2007 -0500, Tres Seaver wrote: >Don't you still need to tell Python about the encoding of your string >literals [1] [2] ? E.g.:: That's not the problem, it's that the code that writes the PKG-INFO file doesn't handle Unicode. See distutils.dist.DistributionMetadata.write_pkg_info(). It needs to use a file with encoding support, if it's doing unicode However, there's currently no standard, as far as I know, for what encoding the PKG-INFO file should use. Meanwhile, the 'register' command accepts Unicode, but is broken in handling it. Essentially, the problem is that Python 2.5 broke this by adding a unicode *requirement* to the "register" command. Previously, register simply sent whatever you gave it, and the PKG-INFO writing code still does. Unfortunately, this means that there is no longer any one value that you can use for your name that will be accepted by both "register" and anything that writes a PKG-INFO file. Both register and write_pkg_info() are arguably broken here, and should be able to work with either strings or unicode, and degrade gracefully in the event of non-ASCII characters in a string. (Because even though "register" is only run by the package's author, users may run other commands that require a PKG-INFO, so a package prepared using Python <2.5 must still be usable with Python 2.5 distutils, and Python <2.5 allows 8-bit maintainer names.) Unfortunately, this isn't fixable until there's a new 2.5.x release. For previous Python versions, both register and write_pkg_info() accepted 8-bit strings and passed them on as-is, so the only workaround for this issue at the moment is to revert to Python 2.4 or less.

4 5

Re: [Python-Dev] And the winner is...
by Mike Coleman April 3, 2009

April 3, 2009

Just for curiosity's sake, could someone outline the five (or so) most significant pluses of hg relative to git? (My personal feeling is that any of the three is a huge improvement over subversion. I think git probably should have been written in Python with some stuff in C where necessary, and (perhaps) the hg guy really is right when he claims that Linus should have skipped git and used hg from the start. That notwithstanding, though, it kind of looks like git has won the mindshare war at this point, and I think the best hg can hope for from this point forward is a sort of *BSD to git's Linux. I do hope that it lives on, shutouts being fascist, etc. Aside: I once worked with the guy maintaining git, and he might have the greatest sum of talent plus humility of any programmer I ever met.)

13 19

Let's update CObject API so it is safe and regular!
by Larry Hastings April 3, 2009

April 3, 2009

The CObject API has two flaws. First, there is no usable type safety mechanism. You can store a void *object, and a void *description. There is no established schema for the description; it could be an integer cast to a pointer, or it could point to memory of any configuration, or it could be NULL. Thus users of the CObject API generally ignore it--thus working without any type safety whatsoever. A programmer could crash the interpreter from pure Python by mixing and matching CObjects from different modules (e.g. give "curses" a CObject from "_ctypes"). Second, the destructor callback is defined as taking *either* one *or* two parameters, depending on whether the "descr" pointer is non-NULL. One can debate the finer points of what is and isn't defined behavior in C, but at its heart this is a sloppy API. MvL and I discussed this last night and decided to float a revision of the API. I wrote the patch, though, so don't blame Martin if you don't like my specific approach. The color of this particular bike shed is: * The PyCObject is now a private data structure; you must use accessors. I added accessors for all the members. * The constructors and the main accessor (PyCObject_AsVoidPtr) now all *require* a "const char *type" parameter, which must be a non-NULL C string of non-zero length. If you call that accessor and the "type" is invalid *or doesn't match*, it fails. * The destructor now takes the PyObject *, not the PyCObject *. You must use accessors to get your hands on the data inside to free it. Yes, you can easily skip around the "matching type" restriction by calling PyCObject_AsVoidPtr(cobj, PyCObject_GetType(cobj)). The point of my API changes is to *encourage* correct use. I've posted a patch implementing this change in the 3.1 trunk to the bug tracker: http://bugs.python.org/issue5630 I look forward to your comments! /larry/

8 24

3to2 Project
by Jesse Noller April 2, 2009

April 2, 2009

During the Language summit this past Thursday, pretty much everyone agreed that a python 3 to python 2 tool would be a very large improvement in helping developers be able to write "pure" python 3 code. The idea being a large project such as Django could completely cut over to Python3, but then run the 3to2 tool on the code based to continue to support version 2.x. I raised my hand to help move this along, I've spoke to Benjamin Peterson, and he's amendable to mentoring a GSoC student for this project and he's already received at least one proposal for this. Additionally, there's been a number of developers here at PyCon who are more than ready to help contribute. So, if people are interested in helping, coordinating work/etc - feel free to sync up with Benjamin - he's started a wiki page here: http://wiki.python.org/moin/3to2 I'll help coordinate where I can! -Jesse

5 6

3.1a2
by Benjamin Peterson April 2, 2009

April 2, 2009

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 April 1, 2009

April 1, 2009

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

Re: [Python-Dev] Broken import?
by Guido van Rossum April 1, 2009

April 1, 2009

[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 April 1, 2009

April 1, 2009

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

Re: [Python-Dev] This seems like a bug - main thread has None ident???
by skip＠pobox.com March 31, 2009

March 31, 2009

skip> Am I missing something obvious or have I hit a bug? This is a skip> fully updated 2.7a0 build, trunk:70878M. After noting that thread.get_ident() returned a thread id but that threading.currentThread().ident was None I concluded that it is, in fact, a bug in the threading module. I opened a ticket: http://bugs.python.org/issue5632 Skip

1 0