Mailman 3 December 2006 - Python-Dev

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 07 Dec '06

07 Dec '06

Patch / Bug Summary ___________________ Patches : 413 open ( +6) / 3489 closed ( +5) / 3902 total (+11) Bugs : 943 open ( +7) / 6364 closed ( +1) / 7307 total ( +8) RFE : 246 open ( +0) / 244 closed ( +0) / 490 total ( +0) New / Reopened Patches ______________________ popen() slow on AIX due to large FOPEN_MAX value (2006-12-01) http://python.org/sf/1607087 opened by John L. Allen bug# 1607041: Condition.wait timeout fails on clock change (2006-12-01) http://python.org/sf/1607149 opened by BC Optional Argument Syntax (2006-12-02) http://python.org/sf/1607548 opened by Tony Lownds Makefile fix (2006-12-03) http://python.org/sf/1608267 opened by Hasan Diwan Race condition in os.makedirs (2006-12-04) http://python.org/sf/1608579 opened by James Bowes Fix pickle doc typo "date", should be "data" (2006-12-04) CLOSED http://python.org/sf/1608758 opened by Graham Horler Py_FileSystemDefaultEncoding can be non-canonical (2006-12-04) http://python.org/sf/1608805 opened by Stephan R.A. Deibel Docstring support for ctypesgen (2006-12-05) CLOSED http://python.org/sf/1609108 opened by David Remahl #1603424 subprocess.py wrongly claims 2.2 compatibility. (2006-12-05) http://python.org/sf/1609282 opened by Robert Carr traceback on exit if syslog handler fails to initialize (2006-12-05) http://python.org/sf/1609407 opened by Jeremy Katz tarfile.py: Fix for bug #1609958 (2006-12-06) CLOSED http://python.org/sf/1610437 opened by Lars Gustäbel Patches Closed ______________ Socket module is not thread-safe (2006-08-22) http://python.org/sf/1544279 closed by loewis ConfigParser to accept a custom dict to allow ordering (2005-12-01) http://python.org/sf/1371075 closed by loewis Fix pickle doc typo "date", should be "data" (2006-12-05) http://python.org/sf/1608758 closed by quiver Docstring support for ctypesgen (2006-12-05) http://python.org/sf/1609108 closed by theller tarfile.py: Fix for bug #1609958 (2006-12-06) http://python.org/sf/1610437 closed by gbrandl New / Reopened Bugs ___________________ Condition.wait timeout fails when system clock changes (2006-12-01) http://python.org/sf/1607041 opened by BC Incorrect use of 'int' and 'long' descriptions (2006-12-01) CLOSED http://python.org/sf/1607061 opened by John logging %(module)s reporting wrong modules (2006-11-29) http://python.org/sf/1605110 reopened by mad-marty segfault in python24.dll (2006-12-03) http://python.org/sf/1607759 opened by joe mailbox.Maildir re-reads directory too often (2006-12-03) http://python.org/sf/1607951 opened by Matthias Klose Sloppy error checking in listdir() for Posix (2006-12-04) http://python.org/sf/1608818 opened by Stephan R.A. Deibel PyThread_release_lock with pthreads munges errno (2006-12-04) http://python.org/sf/1608921 opened by Stephan R.A. Deibel tarfile archive paths limited to less than 100 chars (2006-12-06) CLOSED http://python.org/sf/1609958 opened by Frank Rehberger GUI for Python 2.3, 2.4, and 2.5 is very sluggish (2006-12-06) http://python.org/sf/1610485 opened by g4rlik Bugs Closed ___________ Incorrect use of 'int' and 'long' descriptions (2006-12-01) http://python.org/sf/1607061 closed by gbrandl not configured for tk (2006-10-18) http://python.org/sf/1579931 closed by sf-robot tarfile archive paths limited to less than 100 chars (2006-12-06) http://python.org/sf/1609958 closed by gbrandl

1 0

LSB: Binary compatibility
by "Martin v. Löwis" 06 Dec '06

06 Dec '06

At the LSB meeting, Jeff Licquia asked whether Python could provide binary compatibility with previous versions by use of ELF symbol versioning. In ELF symbol versioning, you can have multiple definitions for the same symbol; clients (e.g. extension modules) would refer to a specific version. During static linking, the most recent (?) version of the symbol is coded into the client object. With symbol versioning, you can change the implementation of a function and even its interface, and it will be compatible as long as you keep the original version around. My first reaction is that this is difficult due to the usage of function-like macros. However, if we replaced those with C functions (perhaps has a compile-time choice), and if we would also hide the layout of structures, I think providing binary compatibility (with a certain baseline version, or multiple of these) would be possible. Of course, several things need to be considered, e.g. - making Py_INCREF/Py_DECREF functions is likely a bad idea for performance reasons. OTOH, it seems safe that Py_INCREF/Py_DECREF can remain as-is for the rest of 2.x. - hiding PyTypeObject is a bad idea for source compatibility. OTOH, we already try to make only compatible changes to it (except when we don't :-), so exposing this as stable ABI might actually work. - certain kinds of modules likely need to be ruled out, e.g. modules that extend the layout of existing types (it would fail to compile because the base struct becomes an incomplete type). All in all, I think providing binary compatibility would be feasible, and should be attempted. What do you think? Regards, Martin

6 10

__str__ and unicode
by Fredrik Lundh 06 Dec '06

06 Dec '06

over at my work copy of the python language reference, Adrian Holovaty asked about the exact semantics of the __str__ hook: http://effbot.org/pyref/__str__ "The return value must be a string object." Does this mean it can be a *Unicode* string object? This distinction is ambiguous to me because unicode objects and string objects are both subclasses of basestring. May a __str__() return a Unicode object? I seem to remember earlier discussions on this topic, but don't recall when and what. From what I can tell, __str__ may return a Unicode object, but only if can be converted to an 8-bit string using the default encoding. Is this on purpose or by accident? Do we have a plan for improving the situation in future 2.X releases ? </F>

5 8

LSB: Selection of a Python version
by "Martin v. Löwis" 06 Dec '06

06 Dec '06

At the LSB meeting, there was a brief discussion of what Python version should be incorporated into LSB. This is more an issue if ABI compatibility for the C ABI is desired, but even if only script portability is a goal, application developers will need to know what APIs they have available in LSB 3.2 and which they don't. LSB codifies existing practice, rather than defining "anticipating" standards, so things get only into LSB if they are already commonplace in distributions. Currently, Python 2.4 is widely available in Linux distributions; Python 2.5 is not and (apparently) will not be included in the next RHEL release (which apparently is coming soon). So it looks like LSB will standardize on Python 2.4 (which will also be the default version in the next Debian release). Regards, Martin

3 6

Distribution tools: What I would like to see
by Talin 06 Dec '06

06 Dec '06

I've been looking once again over the docs for distutils and setuptools, and thinking to myself "this seems a lot more complicated than it ought to be". Before I get into detail, however, I want to explain carefully the scope of my critique - in particular, why I am talking about setuptools on the python-dev list. You see, in my mind, the process of assembling, distributing, and downloading a package is, or at least ought to be, a unified process. It ought to be a fundamental part of the system, and not split into separate tools with separate docs that have to be mentally assembled in order to understand it. Moreover, setuptools is the defacto standard these days - a novice programmer who googles for 'python install tools' will encounter setuptools long before they learn about distutils; and if you read the various mailing lists and blogs, you'll sense a subtle aura of deprecation and decay that surrounds distutils. I would claim, then, that regardless of whether setuptools is officially blessed or not, it is an intrinstic part of the "Python experience". (I'd also like to put forward the disclaimer that there are probably factual errors in this post, or errors of misunderstanding; All I can claim as an excuse is that it's not for lack of trying, and corrections are welcome as always.) Think about the idea of module distribution from a pedagogical standpoint - when does a newbie Python programmer start learning about module distribution and what do they learn first? A novice Python user will begin by writing scripts for themselves, and not thinking about distribution at all. However, once they reach the point where they begin to think about packaging up their module, the Python documentation ought to be able to lead them, step by step, towards a goal of making a distributable package: -- It should teach them how to organize their code into packages and modules -- It should show them how to write the proper setup scripts -- If there is C code involved, it should explain how that fits into the picture. -- It should explain how to write unit tests and where they should go. So how does the current system fail in this regard? The docs for each component - distutils, setuptools, unit test frameworks, and so on, only talk about that specific module - not how it all fits together. For example, the docs for distutils start by telling you how to build a setup script. It never explains why you need a setup script, or why Python programs need to be "installed" in the first place. [1] The distutils docs never describe how your directory structure ought to look. In fact, they never tell you how to *write* a distributable package; rather, it seems to be more oriented towards taking an already-working package and modifying it to be distributable. The setuptools docs are even worse in this regard. If you look carefully at the docs for setuptools, you'll notice that each subsection is effectively a 'diff', describing how setuputils is different from distutils. One section talks about the "new and changed keywords", without explaining what the old keywords were or how to find them. Thus, for the novice programmer, learning how to write a setup script ends up being a process of flipping back and forth between the distutils and setuptools docs, trying to hold in their minds enough of each to be able to achieve some sort of understanding. What we have now does a good job of explaining how the individual tools work, but it doesn't do a good job of answering the question "Starting from an empty directory, how do I create a distributable Python package?" A novice programmer wants to know what to create first, what to create next, and so on. This is especially true if the novice programmer is creating an extension module. Suppose I have a C library that I need to wrap. In order to even compile and test it, I'm going to need a setup script. That means I need to understand distutils before I even think about distribution, before I even begin writing the code! (Sure, I could write a Makefile, but I'd only end up throwing it away later -- so why not cut to the chase and *start* with a setup script? Ans: Because it's too hard!) But it isn't just the docs that are at fault here - otherwise, I'd be posting this on a different mailing list. It seems like the whole architecture is 'diff'-based, a series of patches on top of patches, which are in need of some serious refactoring. Except that nobody can do this refactoring, because there's no formal list of requirements. I look at distutils, and while some parts are obvious, there are other parts where I go "what problem were they trying to solve here?" In my experience, you *don't* go mucking with someone's code and trying to fix it unless you understand what problem they were trying to solve - otherwise you'll botch it and make a mess. Since few people ever bother to write down what problem they were trying to solve (although they tend to be better at describing their clever solution), usually this ends up being done through a process of reverse engineering the requirements from the code, unless you are lucky enough to have someone around who knows the history of the thing. Admittedly, I'm somewhat in ignorance here. My perspective is that of an 'end-user developer', someone who uses these tools but does not write them. I don't know the internals of these tools, nor do I particularly want to - I've got bigger fish to fry. I'm posting this here because what I'd like folks to think about is the whole process of Python development, not just the documentation. What is the smoothest path from empty directory to a finished package on PyPI? What can be changed about the current standard libraries that will ease this process? [1] The answer, AFAICT, is that 'setup' is really a Makefile - in other words, its a platform-independent way of describing how to construct a compiled module from sources, and making it available to all programs on that system. Although this gets confusing when we start talking about "pure python" modules that have no C component - because we have all this language that talks about compiling and installing and such, when all that is really going on underneath is a plain old file copy. -- Talin

4 9

DRAFT: python-dev summary for 2006-11-16 through 2006-11-30
by Steven Bethard 06 Dec '06

06 Dec '06

Here's the summary for the second half of November. As always, corrections and comments are greatly appreciated. If you were involved in the November portions of the LSB discussions, I'd particularly appreciate your reviews of that section. ============= Announcements ============= -------------------------- Python 2.5 malloc families -------------------------- Remember that if you find your extension module is crashing with Python 2.5 in malloc/free, there is a high chance that you have a mismatch in malloc "families". Fredrik Lundh's FAQ has more: http://effbot.org/pyfaq/why-does-my-c-extension-suddenly-crash-under-2.5.htm Contributing thread: - `2.5 portability problems <http://mail.python.org/pipermail/python-dev/2006-November/069971.html>`__ --------------------------------- Roundup tracker schema discussion --------------------------------- If you'd like to be involved in the discussion of the setup for the `new tracker`_, you can now file issues on the `meta tracker`_ or post to the `tracker-discuss mailing list`_. Be sure to sign up for an account so your comments don't show up as anonymous! .. _new tracker: http://psf.upfronthosting.co.za/roundup/tracker/ .. _meta tracker: http://psf.upfronthosting.co.za/roundup/meta/ .. _tracker-discuss mailing list: http://mail.python.org/mailman/listinfo/tracker-discuss Contributing thread: - `discussion of schema for new issue tracker starting <http://mail.python.org/pipermail/python-dev/2006-November/069976.html>`__ ========= Summaries ========= ---------------------------------------- Python and the Linux Standard Base (LSB) ---------------------------------------- Ian Murdock, the chair of the Linux Standard Base (LSB), explained that they wanted to add Python to `LSB 3.2`_. Martin v. Löwis promised to go to their meeting in Berlin and report back to python-dev. The discussion then turned to the various ways in which the different Linux variants package Python. A number of people had been troubled by Debian's handling of distutils. At one point, Debian had excluded distutils completely, requiring users to install the "python-dev" package to get distutils functionality. While current versions of Debian had put distutils back in the stdlib, they had excluded the ``config`` directory, meaning that distutils worked only for pure Python modules, not extension modules. And because Debian had no way of knowing that a computer with both gcc and Python installed would likely benefit from having the ``config`` directory installed, the user still had to install "python-dev" separately. There was also some discussion about how to handle third party modules so that updating a module didn't break some application which was expecting a different version. These kinds of problems were particularly dangerous on distributions like Gentoo and Ubuntu which relied heavily on their own system Python for the OS to work properly. Guido suggested introducing a vendor-packages directory for the third party modules required by the OS and Martin v. Löwis reopened an `earlier patch`_ suggesting this. A number of folks also thought that adding a ~/.local/lib/pythonX.X/site-packages directory for user specific (not site wide) packages could be useful. Phillip J. Eby pointed out that distutils and setuptools already allow you to install packages this way by putting:: [install] prefix = ~/.local into ./setup.cfg, ~/.pydistutils.cfg, or /usr/lib/python2.x/distutils/distutils.cfg. He also explained that setuptools could address some of the application-level problems: setuptools-generated scripts adjust their sys.path to include the specific eggs they need, and can specify these eggs with an exact version if necessary. Thus OS-level scripts would likely specify exact versions and then users could feel free to install newer eggs without worrying that the OS would try to use them instead. .. _LSB 3.2: http://www.freestandards.org/en/LSB_Roadmap .. _earlier patch: http://bugs.python.org/1298835 Contributing thread: - `Python and the Linux Standard Base (LSB) <http://mail.python.org/pipermail/python-dev/2006-November/070027.html>`__ ---------------------- Thread-safe operations ---------------------- Fredrik Lundh has been working on a `new Python FAQ`_ and asked about what kinds of operations could be considered "atomic" for the purposes of thread-safety. While almost any statement in Python can invoke an arbitrary special method (e.g. ``a = b`` can invoke ``a.__del__()``), Fredrik was interested in situations where the objects involved were either builtins or objects that didn't override special methods. In situations like these, you can be guaranteed things like:: * If two threads execute ``L.append(x)``, two items will be added to the list (though the order is unspecified) * If two threads execute ``x.y = z``, the field ``y`` on the ``x`` object will exist and contain one of the values assigned by one of the threads You get these guarantees mainly because the core operation in these examples involves only a single Python bytecode. However, Martin v. Löwis pointed out that even the above examples are not truly atomic in the strictest sense because they invoke bytecodes to load the values of the variables in addition to the bytecode to perform the operation. For example, if one thread does ``x = y`` while another thread does ``y = x``, at the end of the code in an "atomic" system, both ``x`` and ``y`` would have the same value. However, in Python, the values could get swapped if a context switch occurred between the loading of the values and the assignment operations. Much of this discussion was also posted to `the FAQ item`_. .. _new Python FAQ: http://effbot.org/pyfaq/ .. _the FAQ item: http://effbot.org/pyfaq/what-kinds-of-global-value-mutation-are-thread-safe… Contributing thread: - `PyFAQ: thread-safe interpreter operations <http://mail.python.org/pipermail/python-dev/2006-November/069981.html>`__ -------------------------------------------- From an empty directory to a package on PyPI -------------------------------------------- Talin suggested that distutils/setuptools and their documentation should be updated so that new users could more easily answer the question: "What is the smoothest path from empty directory to a finished package on PyPI?" In particular, Talin thought that having to cross-reference between distutils/setuptools/unittest/etc. was confusing, and that a more stand-alone version of the documentation was necessary. A number of people agreed that the documentation could use some reorganization and the addition of some more tutorial-like sections. Mike Orr promised to put together an initial "Table of Contents" that would have links to the most important information for package distribution, and Talin promised to make his notes available on the "baby steps" necessary to prepare a module for setuptools (e.g. create the directory structure, write a setup.py file, create source files in the appropriate directories, etc.) Contributing thread: - `Distribution tools: What I would like to see <http://mail.python.org/pipermail/python-dev/2006-November/070034.html>`__ -------------------------------------------- Monitoring progress with urllib's reporthook -------------------------------------------- Martin v. Löwis looked at a `patch to urllib's reporthook`_ aimed at more accurate progress reporting. The original code in urllib was passing the ``read()`` block size as the second argument to the reporthook. The patch would have instead passed as the second argument the actual count of bytes read. Guido pointed out that the block size and the actual count would always be identical except for the last block because of how Python's ``file.read(n)`` works. Thus urllib was already giving the reporthook as accurate a progress report as possible given the implementation, and so the patch was rejected. .. _patch to urllib's reporthook: http://bugs.python.org/849407 Contributing thread: - `Passing actual read size to urllib reporthook <http://mail.python.org/pipermail/python-dev/2006-November/069977.html>`__ --------------------------- Infinity and NaN singletons --------------------------- Tomer Filiba asked about making the positive-infinity, negative-infinity and not-a-number (NaN) singletons available as attributes of the ``float`` type, e.g. ``float.posinf``, ``float.neginf`` and ``float.nan``. Bob Ippolito pointed him to `PEP 754`_ and the fpconst_ module which addressed some of these issues though in a separate module instead of the builtin ``float`` type. When Tomer asked why `PEP 754`_ had not been accepted, Martin v. Löwis explained that while people were interested in the feature, it was difficult to implement in general, e.g. on platforms where the double type was not IEEE-754. .. _PEP 754: http://www.python.org/dev/peps/pep-0754/ .. _fpconst: http://www.python.org/pypi/fpconst/ Contributing thread: - `infinities <http://mail.python.org/pipermail/python-dev/2006-November/070020.html>`__ ------------------------------------------ Line continuations and the tokenize module ------------------------------------------ Guido asked about modifying the tokenize module to allow a better round-tripping of code with line continuations. While the tokenize module was generating pseudo-tokens for things like comments and "ignored" newlines, it was not generating anything for line continuation backslashes. Adding the appropriate yield would have been trivial, but would have been a (minor) backwards incompatible change. Phillip J. Eby pointed Guido to `scale.dsl`_ which dealt with similar issues, and suggested that even though the change was small, it might cause problems for some existing tools. Guido proposed a somewhat more backwards compatible version, where a NL pseudo-token was generated with '\\\n' as its text value, and asked folks to try it out and see if it gave them any trouble. .. _scale.dsl: http://peak.telecommunity.com/DevCenter/scale.dsl#converting-tokens-back-to… Contributing thread: - `Small tweak to tokenize.py? <http://mail.python.org/pipermail/python-dev/2006-November/070099.html>`__ ----------------------- Summer of Code projects ----------------------- Georg Brandl asked about the status of the Google Summer of Code projects and got a number of responses: * Nilton Volpato reported the completion of the new ziparchive_ module, which includes file-like access to zip members, support for BZIP2 compression, support for member file removal and support for encryption. He explained that he was still doing a little work to clean up the API, and that he would appreciate any feedback people had on the module. * Facundo Batista reported that the decimal Python-to-C transliteration was completed successfully, but that they learned in the process that a simple transliteration was not going to suffice and the decimal module was going to have to undergo a structural redesign to perform well in C. * Jim Jewett reported that the work to make more stdlib modules use the logging module was incomplete, and not ready for stdlib inclusion yet. .. _ziparchive: http://ziparchive.sourceforge.net/ Contributing threads: - `Summer of Code: zipfile? <http://mail.python.org/pipermail/python-dev/2006-November/069955.html>`__ - `Results of the SOC projects <http://mail.python.org/pipermail/python-dev/2006-November/069968.html>`__ - `Summer of Code: zipfile? <http://mail.python.org/pipermail/python-dev/2006-November/069969.html>`__ - `Results of the SOC projects <http://mail.python.org/pipermail/python-dev/2006-November/069970.html>`__ =============== Skipped Threads =============== - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-November/069973.html>`__ - `Python in first-year MIT core curriculum <http://mail.python.org/pipermail/python-dev/2006-November/069974.html>`__ - `POSIX Capabilities <http://mail.python.org/pipermail/python-dev/2006-November/069986.html>`__ - `[1593035] Re: readline problem with python-2.5 <http://mail.python.org/pipermail/python-dev/2006-November/069987.html>`__ - `DRAFT: python-dev summary for 2006-10-01 to 2006-10-15 <http://mail.python.org/pipermail/python-dev/2006-November/069990.html>`__ - `Suggestion/ feature request <http://mail.python.org/pipermail/python-dev/2006-November/069993.html>`__ - `DRAFT: python-dev summary for 2006-10-16 to 2006-10-31 <http://mail.python.org/pipermail/python-dev/2006-November/070009.html>`__ - `DRAFT: python-dev summary for 2006-11-01 to 2006-11-15 <http://mail.python.org/pipermail/python-dev/2006-November/070012.html>`__ - `ctypes and powerpc <http://mail.python.org/pipermail/python-dev/2006-November/070016.html>`__ - `(no subject) <http://mail.python.org/pipermail/python-dev/2006-November/070028.html>`__ - `Cloning threading.py using processes <http://mail.python.org/pipermail/python-dev/2006-November/070048.html>`__ - `Objecttype of 'locals' argument in PyEval_EvalCode <http://mail.python.org/pipermail/python-dev/2006-November/070071.html>`__

2 1

a feature i'd like to see in python #1: better iteration control
by Ben Wing 05 Dec '06

05 Dec '06

many times writing somewhat complex loops over lists i've found the need to sometimes delete an item from the list. currently there's no easy way to do so; basically, you have to write something like i = 0 while i < len(list): el = list[i] ...do something... if el should be deleted: del list[i] else: i += 1 note that you can't write for x in list: or even for i in xrange(len(list)): note also that you need to do some trickiness to adjust the index appropriately when deleting. i'd much rather see something like: for x:iter in list: ...do something... if x should be deleted: iter.delete() the idea is that you have a way of retrieving both the element itself and the iterator for the element, so that you can then call methods on the iterator. it shouldn't be too hard to implement iter.delete(), as well as iter.insert() and similar functions. (the recent changes to the generator protocol in 2.5 might help.) the only question then is how to access the iterator. the syntax i've proposed, with `x:iter', seems fairly logical (note that parallels with slice notation, which also uses a colon) and doesn't introduce any new operators. (comma is impossible since `for x,iter in list:' already has a meaning) btw someone is probably going to come out and say "why don't you just use a list comprehension with an `if' clause? the problems are [1] i'd like this to be destructive; [2] i'd like this to work over non-lists as well, e.g. hash-tables; [3] list comprehensions work well in simple cases, but in more complicated cases when you may be doing various things on each step, and might not know whether you need to delete or insert an element until after you've done various other things, a list comprehension would not fit naturally; [4] this mechanism is extendible to insertions, replacements and other such changes as well as just filterings. ben

6 13

Next PyPy sprint: Leysin 8-14th January 2007
by Armin Rigo 05 Dec '06

05 Dec '06

Hi all, ===================================================================== PyPy Leysin Winter Sports Sprint (8-14th January 2007) ===================================================================== .. image:: http://www.ermina.ch/002.JPG The next PyPy sprint will be in Leysin, Switzerland, for the fourth time. This sprint will be the final public sprint of our EU-funded period, and a kick-off for the final work on the upcoming PyPy 1.0 release (scheduled for mid-February). The sprint is the last chance for students looking for a "summer" job with PyPy this winter! If you have a proposal and would like to work with us in the mountains please send it in before 15th December to "pypy-tb at codespeak.net" and cross-read this page: http://codespeak.net/pypy/dist/pypy/doc/summer-of-pypy.html ------------------------------ Goals and topics of the sprint ------------------------------ * Like previous winter, the main side goal is to have fun in winter sports :-) We can take a couple of days off for ski; at this time of year, ski days end before 4pm, which still leaves plenty of time to recover (er, I mean hack). * Progress on the JIT compiler, which we are just starting to scale to the whole of PyPy. `[1]`_ * Polish the code and documentation of the py lib, and eventually release it. * Work on prototypes that use the new features that PyPy enables: distribution `[2]`_ (based on transparent proxying `[3]`_), security `[4]`_, persistence `[5]`_, etc. `[6]`_. .. _[1]: http://codespeak.net/pypy/dist/pypy/doc/jit.html .. _[2]: http://codespeak.net/svn/pypy/dist/pypy/lib/distributed/ .. _[3]: http://codespeak.net/pypy/dist/pypy/doc/proxy.html .. _[4]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html#security .. _[5]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html#persistence .. _[6]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html ----------------------- Location & Accomodation ----------------------- Leysin, Switzerland, "same place as before". Let me refresh your memory: both the sprint venue and the lodging will be in a very spacious pair of chalets built specifically for bed & breakfast: http://www.ermina.ch/. The place has a baseline ADSL Internet connexion (600Kb) with wireless installed. You can of course arrange your own lodging anywhere (so long as you are in Leysin, you cannot be more than a 15 minute walk away from the sprint venue), but I definitely recommend lodging there too -- you won't find a better view anywhere else (though you probably won't get much worse ones easily, either :-) I made pre-reservations in the Chalet, so please *confirm* quickly that you are coming so that we can adjust the reservations as appropriate. The rate so far has been 60 CHF a night all included in 2-person rooms, with breakfast. There are larger rooms too (less expensive, possibly more available too) and the possibility to get a single room if you really want to. Please register by svn: http://codespeak.net/svn/pypy/extradoc/sprintinfo/leysin-winter-2007/people… or on the pypy-sprint mailing list if you do not yet have check-in rights: http://codespeak.net/mailman/listinfo/pypy-sprint You need a Swiss-to-(insert country here) power adapter. There will be some Swiss-to-EU adapters around - bring a EU-format power strip if you have one. ----------- Exact times ----------- Officially, 8th-14th January 2007. Both dates are flexible, you can arrive or leave earlier or later, though it is recommended to arrive on the 7th (if many people arrive on the 6th we need to check for accomodation availability first). We will give introductions and tutorials on the 8th, in the morning if everybody is there, or in the afternoon otherwise. -------------------------------------- Armin

1 0

Re: [Python-Dev] Python and LSB: Meeting Report
by "Martin v. Löwis" 05 Dec '06

05 Dec '06

> [private, but feel free to respond on-list] >> - Allow Python scripts to run unmodified across Linux distributions >> - Optional: Allow extension modules to be used in binary form across >> distributions >> - Optional: Allow extension modules to be used in binary form across >> distributions > > Was this duplication of last two points cut'n'paste error or what? Oops, yes, it should have read - Optional: Allow installation of binary foreign Python add-on packages Thanks, Martin

1 0

Re: [Python-Dev] Virtual Python (was Re: Python and the Linux Standard Base (LSB))
by Phillip J. Eby 04 Dec '06

04 Dec '06

At 11:38 AM 12/4/2006 -0800, Mike Orr wrote: >The other approaches work fine for giving each user a private install >dir, but don't address the case of the same user wanting different >install dirs for different projects. For instance, when exploring >Pylons or TurboGears which install a lot of packages I may not >otherwise want, I create a Virtual Python for each of them. If I'm >developing an application under Virtual Python, I can see at a glance >which packages my project needs installed. I can't think of any other >way except Virtual Python to do this. Simply install the packages to an arbitrary directory using -m (--multi-version), and allow the scripts to be installed to the same directory. When the scripts are run, they'll find their eggs in the script directory. Neither PYTHONPATH manipulation nor virtual Pythons are needed to achieve this - it's a self-contained single-application directory. (It will still have to import pkg_resources from a copy of setuptools installed somewhere else, e.g. on PYTHONPATH or in site-packages, or someday perhaps the stdlib.) >Another point. Setuptools seems to have Two Ways To Do Things >regarding package activiation. easy_install puts the latest-installed >egg version in its .pth file so it's automatically available via a >naive "import". This happens to clutters sys.path with a more >entries than some people desire. Using -m (--multi-version) suppresses this behavior. The "just works" behavior of automatically adding to sys.path is just the default. > Meanwhile, programs can use >pkg_resources to activate a package or version that may not already be >in sys.path. Is this the Way Of The Future? Should people start >using pkg_resources for all packages they import? No. Setuptools automatically wraps generated scripts with pkg_resources-based activation, so there's almost never a need to request packages. So, if you need dynamic access for a project, just create yourself a setup.py for it and put the requirements in there. Then run "setup.py develop" to generate wrappers for your scripts. The wrappers will do all the activation for you when they're run. >Finally, one can use ~/.pydistutils.cfg to specify an install >location, but that again allows only one location per user. One *default* location per user... per current directory. Since it's based on distutils, easy_install always reads setup.cfg from the current directory, which can set the defaults. And of course, using -d (--install-dir) on the command line lets you specify a one-off target. >Do the PYTHONPATH improvements make it possible to just put a >directory on your PYTHONPATH and have Python process .pth files in it >without using the site.addsitedir() hack? That would probably be my >biggest wishlist item. Yes, it does -- but it only works for packages installed by easy_install; a special 'site.py' is added to the directory that adds the necessary hooks around the "real" 'site' module's processing.

1 0

LSB: pyc stability
by "Martin v. Löwis" 04 Dec '06

04 Dec '06

Some people (Robert Schweikert) requested byte-code stability at the LSB meeting: LSB should standardize a certain version of the byte code, and then future versions of Python should continue to support this byte code version. I explained that this is currently not supported, but would be technically possible; somebody would have to implement it. What do you think? Regards, Martin

4 5

Polling with Pending Calls?
by Tony Nelson 04 Dec '06

04 Dec '06

I think I have a need to handle *nix signals through polling in a library. It looks like chaining Pending Calls is almost the way to do it, but I see that doing so would make the interpreter edgy. The RPM library takes (steals) the signal handling away from its client application. It has good reason to be so paranoid, but it breaks the handling keyboard interrupts, especially if rpmlib is used in the normal way: opened at the beginning, various things are done by the app, closed at the end. If there is an extended period in the middle where no calls are made to rpmlib (say, in yum during the downloading of packages or package headers), then responst to a keyboard interrupt can be delayed for /minutes/! Yum is presently doing something awful to work around that issue. It is possible to poll rpmlib to find if there is a pending keyboard interrupt. Client applications could have such polls sprinkled throughout them. I think getting yum, for example, to do that might be politically difficult. I'm hoping to propose a patch to rpmlib's Python bindings to do the polling automagically. Looking at Python's normal signal handling, I see that Py_AddPendingCall() and Py_MakePendingCalls(), and PyEvel_EvalFrameEx()'s ticker check are how signals and other async events are done. I could imagine making rpmlib's Python bindings add a Pending Call when the library is loaded (or some such), and that Pending Call would make a quick check of rpmlib's caught signals flags and then call Py_AddPendingCall() on itself. It appears that this would work, and is almost the expected thing to do, but unfortunately it would cause the ticker check to think that Py_MakePendingCalls() had failed and needed to be called again ASAP, which would drastically slow down the interpreter. Is there a right way to get the Python interpreter to poll something, or should I look for another approach? [I hope this message doesn't spend too many days in the grey list limbo.] -- ____________________________________________________________________ TonyN.:' The Great Writ <mailto:tonynelson@georgeanelson.com> ' is no more. <http://www.georgeanelson.com/>

2 2

Virtual Python (was Re: Python and the Linux Standard Base (LSB))
by Mike Orr 04 Dec '06

04 Dec '06

This may be a bit too FAQ-ish for some people but I'll post it in case anybody benefits from the answer. On 11/30/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: > At 02:46 PM 11/30/2006 -0800, Mike Orr wrote: > >Speaking of Virtual Python [1], I've heard some people recommending it > >as a general solution to the "this library breaks that other > >application" problem and "this app needs a different version of X > >library than that other app does". > > It was actually created to help people who don't have root access (e.g. in > shared web hosting accounts) get their "own" Python. It does work for > other things, but I haven't been especially recommending it for anything > besides that, since eggs take care of multi-version app/library support > quite nicely. > > Indeeed, the virtual-python approach is itself unnecessary now, as > easy_install has much better PYTHONPATH support now, than when > virtual-python was created. What does this last part mean? Virtual Python is still one of the four recommended ways to set up a custom install location in the EasyInstall docs. http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-loc… The other approaches work fine for giving each user a private install dir, but don't address the case of the same user wanting different install dirs for different projects. For instance, when exploring Pylons or TurboGears which install a lot of packages I may not otherwise want, I create a Virtual Python for each of them. If I'm developing an application under Virtual Python, I can see at a glance which packages my project needs installed. I can't think of any other way except Virtual Python to do this. Another point. Setuptools seems to have Two Ways To Do Things regarding package activiation. easy_install puts the latest-installed egg version in its .pth file so it's automatically available via a naive "import". This happens to clutters sys.path with a more entries than some people desire. Meanwhile, programs can use pkg_resources to activate a package or version that may not already be in sys.path. Is this the Way Of The Future? Should people start using pkg_resources for all packages they import? (That would also allow one to remove little-used packages from easy-install.pth.) Finally, one can use ~/.pydistutils.cfg to specify an install location, but that again allows only one location per user. And in the case of root, it can't distinguish between manually-installed packages and OS-installed packages, which the admin might want in different directories (/usr/local/lib/python vs /usr/lib/pythonVERSION). This hasn't been an issue because OSes haven't been using easy_install or eggs, but it will be when they start doing so. Do the PYTHONPATH improvements make it possible to just put a directory on your PYTHONPATH and have Python process .pth files in it without using the site.addsitedir() hack? That would probably be my biggest wishlist item. -- Mike Orr <sluggoster(a)gmail.com>

1 0

Re: [Python-Dev] Polling with Pending Calls?
by Gustavo Carneiro 04 Dec '06

04 Dec '06

This patch may interest you: http://www.python.org/sf/1564547 Not sure it completely solves your case, but it's at least close to your problem. On 12/4/06, Tony Nelson <tonynelson(a)georgeanelson.com> wrote: > > I think I have a need to handle *nix signals through polling in a library. > It looks like chaining Pending Calls is almost the way to do it, but I see > that doing so would make the interpreter edgy. > > The RPM library takes (steals) the signal handling away from its client > application. It has good reason to be so paranoid, but it breaks the > handling keyboard interrupts, especially if rpmlib is used in the normal > way: opened at the beginning, various things are done by the app, closed > at the end. If there is an extended period in the middle where no calls > are made to rpmlib (say, in yum during the downloading of packages or > package headers), then responst to a keyboard interrupt can be delayed for > /minutes/! Yum is presently doing something awful to work around that > issue. > > It is possible to poll rpmlib to find if there is a pending keyboard > interrupt. Client applications could have such polls sprinkled throughout > them. I think getting yum, for example, to do that might be politically > difficult. I'm hoping to propose a patch to rpmlib's Python bindings to > do > the polling automagically. > > Looking at Python's normal signal handling, I see that Py_AddPendingCall() > and Py_MakePendingCalls(), and PyEvel_EvalFrameEx()'s ticker check are > how > signals and other async events are done. I could imagine making rpmlib's > Python bindings add a Pending Call when the library is loaded (or some > such), and that Pending Call would make a quick check of rpmlib's caught > signals flags and then call Py_AddPendingCall() on itself. It appears > that > this would work, and is almost the expected thing to do, but unfortunately > it would cause the ticker check to think that Py_MakePendingCalls() had > failed and needed to be called again ASAP, which would drastically slow > down the interpreter. > > Is there a right way to get the Python interpreter to poll something, or > should I look for another approach? > > [I hope this message doesn't spend too many days in the grey list limbo.] > -- > ____________________________________________________________________ > TonyN.:' The Great Writ <mailto:tonynelson@georgeanelson.com> > ' is no more. <http://www.georgeanelson.com/> > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com > -- Gustavo J. A. M. Carneiro "The universe is always one step beyond logic."

2 1

Python and LSB: Meeting Report
by "Martin v. Löwis" 04 Dec '06

04 Dec '06

We just had (the first day of) an LSB face-to-face meeting today [1], where Python was discussed. I started with presenting my slides, and stated what I see as main goals: - Allow Python scripts to run unmodified across Linux distributions - Optional: Allow extension modules to be used in binary form across distributions - Optional: Allow extension modules to be used in binary form across distributions During the discussion, Robert Schweikert proposed another goal, from the view of a proprietary software vendor: - Allow .pyc files to run unmodified across Linux distributions The discussion evolved around backwards compatibility. I'll start separate threads for these; here is the summary: - LSB attempts to guarantee backwards compatibility with previous versions (starting with 4.0; currently, 3.2 is targeted). Linux distributions implementing future LSB versions should be backwards-compatible with previous LSB versions. - Removal of features can only occur after three major LSB releases; this means all features will stay for about 6 years - If LSB integrated a specific version now, that version will have to be supported by vendors for those 6 years - given that the Python ABI changes frequently over time, this makes standardization of the ABI difficult - even for API (i.e. library interfaces), backwards-compatibility would be difficult: for those packages/classes/modules/functions that become part of the LSB API, stability would be desirable. Regards, Martin [1] http://www.freestandards.org/en/LSB_face-to-face_(December_2006) [2]http://www.freestandards.org/images/6/66/Lsb-f2f-200612-python.pdf

1 0

Makefile.pre.in Patch
by Hasan Diwan 04 Dec '06

04 Dec '06

The attached patch ensures that the $(DESTDIR) exists before installing the built binaries. It has been tested on Mac OS X. The patch is attached. -- Cheers, Hasan Diwan <hasan.diwan(a)gmail.com>

2 1

Re: [Python-Dev] Small tweak to tokenize.py?
by Phillip J. Eby 02 Dec '06

02 Dec '06

At 09:49 AM 11/30/2006 -0800, Guido van Rossum wrote: >I've got a small tweak to tokenize.py that I'd like to run by folks here. > >I'm working on a refactoring tool for Python 2.x-to-3.x conversion, >and my approach is to build a full parse tree with annotations that >show where the whitespace and comments go. I use the tokenize module >to scan the input. This is nearly perfect (I can render code from the >parse tree and it will be an exact match of the input) except for >continuation lines -- while the tokenize gives me pseudo-tokens for >comments and "ignored" newlines, it doesn't give me the backslashes at >all (while it does give me the newline following the backslash). The following routine will render a token stream, and it automatically restores the missing \'s. I don't know if it'll work with your patch, but perhaps you could use it instead of changing tokenize. For the documentation and examples, see: http://peak.telecommunity.com/DevCenter/scale.dsl#converting-tokens-back-to… def detokenize(tokens, indent=0): """Convert `tokens` iterable back to a string.""" out = []; add = out.append lr,lc,last = 0,0,'' baseindent = None for tok, val, (sr,sc), (er,ec), line in flatten_stmt(tokens): # Insert trailing line continuation and blanks for skipped lines lr = lr or sr # first line of input is first line of output if sr>lr: if last: if len(last)>lc: add(last[lc:]) lr+=1 if sr>lr: add(' '*indent + '\\\n'*(sr-lr)) # blank continuation lines lc = 0 # Re-indent first token on line if lc==0: if tok==INDENT: continue # we want to dedent first actual token else: curindent = len(line[:sc].expandtabs()) if baseindent is None and tok not in WHITESPACE: baseindent = curindent elif baseindent is not None and curindent>=baseindent: add(' ' * (curindent-baseindent)) if indent and tok not in (DEDENT, ENDMARKER, NL, NEWLINE): add(' ' * indent) # Not at start of line, handle intraline whitespace by retaining it elif sc>lc: add(line[lc:sc]) if val: add(val) lr,lc,last = er,ec,line return ''.join(out)

3 5

OT: World's oldest ritual discovered. Worshipped the python 70, 000 years ago
by Oleg Broytmann 02 Dec '06

02 Dec '06

http://www.apollon.uio.no/vis/art/2006_4/Artikler/python_english (-: Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd(a)phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

5 5

fpectl: does a better implementation make sense?
by Giovanni Bajo 01 Dec '06

01 Dec '06

Hello, I spent my last couple of hourse reading several past threads about fpectl. If I'm correct 1) fpectl is scheduled for deletion in 2.6. 2) The biggest problem is that the C standard says that it's undefined to return from a SIGFPE handler. Thus, it's impossible to traps floating point exceptions and convert them to Python exceptions in a way that really works. 3) Moreover, the current implementation of PyFPE_* macros (turning on/off the traps + setjmp) are pretty slow, so they're off by default. Now, I would like Python to rause exceptions (FloatingPointError) whenever a Inf or NaN is computed or used in calculations (which to the best of my little understanding of 754 basically means that I want all FPU errors to be detected and handled). I am not arguing that this should be the default behaviour, I'm just saying that I would like if there was a way to enable this (even if only at Python compile time, in fact). I read that Tim Peters suggested several times to rewrite fpectl so that it does not use traps/signals at all, but just checks the FPU bits to see if there was a FPU error. Basically, the PyFPE BEGIN macro would clear the FPU bits, and the STOP macro would check for FPU errors and raise an appropriate exception if needed. Is this suggestion still valid or people changed their mind meanwhile? Would such a rewrite of fpectl (or a new module with a different name) be accepted? -- Giovanni Bajo

2 1

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 01 Dec '06

01 Dec '06

Patch / Bug Summary ___________________ Patches : 407 open ( +1) / 3484 closed ( +5) / 3891 total ( +6) Bugs : 936 open ( +5) / 6363 closed (+14) / 7299 total (+19) RFE : 246 open ( +1) / 244 closed ( +0) / 490 total ( +1) New / Reopened Patches ______________________ sys.id() and sys.intern() (2006-11-23) http://python.org/sf/1601678 opened by Georg Brandl clarify comparison return values (2006-11-24) http://python.org/sf/1602128 opened by Jim Jewett non-framework built python fails to define environ properly (2006-11-23) http://python.org/sf/1602133 opened by paul Suggest a textlist() method for ElementTree (2006-11-24) http://python.org/sf/1602189 opened by Raymond Hettinger subprocess: error redirecting i/o from non-console process (2006-11-27) http://python.org/sf/1603907 opened by Oren Tirosh Performance boost for array repeat (2006-11-28) CLOSED http://python.org/sf/1605020 opened by Mike Klaas Make Imap Error more helpful (2006-11-29) http://python.org/sf/1605192 opened by Thomas Guettler vendor-packages directory. (2005-09-22) http://python.org/sf/1298835 reopened by loewis Patches Closed ______________ __bool__ instead of __nonzero__ (2006-11-21) http://python.org/sf/1600346 closed by jackdied SRE engine do not release the GIL (2005-11-25) http://python.org/sf/1366311 closed by eric_noyau Implement lazy read for sockets (2003-12-04) http://python.org/sf/853963 closed by loewis Disable POSIX for certain/older NetBSD versions (2003-12-05) http://python.org/sf/854796 closed by loewis Performance boost for array repeat (2006-11-28) http://python.org/sf/1605020 closed by mklaas New / Reopened Bugs ___________________ using python extension(wxPython) in c (2006-11-23) CLOSED http://python.org/sf/1601607 opened by jolleydtan getopt Documentation improvement (2006-11-23) CLOSED http://python.org/sf/1601630 opened by Thomas Guettler Incorrect docs for bisect_left (2006-11-24) http://python.org/sf/1602378 opened by Daniel Eloff itemconfigure returns incorrect text property of text items (2006-11-25) http://python.org/sf/1602742 opened by Wojciech Mula wave module forgets to close file on exception (2006-11-26) http://python.org/sf/1603150 opened by amerinese wave module forgets to close file on exception (2006-11-26) CLOSED http://python.org/sf/1603246 opened by amerinese pstats module (profiler) doens't support unicode paths (2006-11-26) CLOSED http://python.org/sf/1603321 opened by Adal Chiriliuc def foo(((x))) segfault (2006-11-26) CLOSED http://python.org/sf/1603332 opened by Tony Lownds f=open fails with TypeError (2006-11-26) CLOSED http://python.org/sf/1603336 opened by Gibholio f=open fails with TypeError (2006-11-26) CLOSED http://python.org/sf/1603412 opened by Gibholio subprocess.py (py2.5) wrongly claims py2.2 compatibility (2006-11-27) http://python.org/sf/1603424 opened by Tim Wegener Python socket library confused by IPV6 notation in /etc/host (2006-11-27) http://python.org/sf/1603527 opened by Eric S. Raymond SaveConfigParser.write() doesn't quote %-Sign (2006-11-27) http://python.org/sf/1603688 opened by Rebecca Breu grammatical error in Python Library Reference::Tkinter (2006-11-27) CLOSED http://python.org/sf/1603789 opened by Gabriel M. Elder subprocess.Popen closes fds for sys.stdout or sys.stderr (2006-11-28) http://python.org/sf/1604851 opened by Nishkar Grover _CRT_SECURE_NO_DEPRECATE macro redefinition with VC++ 8 (2006-11-28) CLOSED http://python.org/sf/1604862 opened by William Fulton logging %(module)s reporting wrong modules (2006-11-29) http://python.org/sf/1605110 opened by Mad-Marty csv module broken for unicode (2006-11-30) http://python.org/sf/1606092 opened by JettLogic readline on popen3 file returns empty string before end (2006-11-30) http://python.org/sf/1606233 opened by Bill Wallace Bugs Closed ___________ utf_8_sig decode fails with buffer input (2006-11-23) http://python.org/sf/1601501 closed by doerwalter using python extension(wxPython) in c (2006-11-23) http://python.org/sf/1601607 closed by loewis getopt Documentation improvement (2006-11-23) http://python.org/sf/1601630 closed by gbrandl ctypes Structure allows recursive definition (2006-11-17) http://python.org/sf/1598620 closed by theller 2.4 & 2.5 can't create win installer on linux (2006-10-04) http://python.org/sf/1570417 closed by loewis wave module forgets to close file on exception (2006-11-26) http://python.org/sf/1603246 closed by gbrandl pstats module (profiler) doens't support unicode paths (2006-11-26) http://python.org/sf/1603321 closed by gbrandl def foo(((x))) segfault (2006-11-26) http://python.org/sf/1603332 closed by gbrandl f=open fails with TypeError (2006-11-26) http://python.org/sf/1603336 closed by gbrandl f=open fails with TypeError (2006-11-26) http://python.org/sf/1603412 closed by nnorwitz grammatical error in Python Library Reference::Tkinter (2006-11-27) http://python.org/sf/1603789 closed by gbrandl read() in windows stops on chr(26) (2006-11-13) http://python.org/sf/1595822 closed by sf-robot _ctypes built with GCC on AIX 5.3 fails with ld ffi error (2006-09-23) http://python.org/sf/1563807 closed by theller _CRT_SECURE_NO_DEPRECATE macro redefinition with VC++ 8 (2006-11-28) http://python.org/sf/1604862 closed by loewis "make install" for Python 2.4.4 not working properly (2006-10-19) http://python.org/sf/1580563 closed by sf-robot

1 0

Re: [Python-Dev] Python and the Linux Standard Base (LSB)
by glyph＠divmod.com 01 Dec '06

01 Dec '06

On 09:34 am, jack.jansen(a)cwi.nl wrote: >There's another standard place that is searched on MacOS: a per-user >package directory ~/Library/Python/2.5/site-packages (the name "site- >packages" is a misnomer, really). Standardising something here is >less important than for vendor-packages (as the effect can easily be >gotten by adding things to PYTHONPATH) but it has one advantage: >distutils and such could be taught about it and provide an option to >install either systemwide or for the current user only. Yes, let's do that, please. I've long been annoyed that site.py sets up a local user installation directory, a very useful feature, but _only_ on OS X. I've long since promoted my personal hack to add a local user installation directory into a public project -- divmod's "Combinator" -- but it would definitely be preferable for Python to do something sane by default (and have setuptools et. al. support it). I'd suggest using "~/.local/lib/pythonX.X/site-packages" for the "official" UNIX installation location, since it's what we're already using, and ~/.local seems like a convention being slowly adopted by GNOME and the like. I don't know the cultural equivalent in Windows - "%USERPROFILE%\Application Data\PythonXX" maybe? It would be nice if site.py would do this in the same place as it sets up the "darwin"-specific path, and to set that path as a module global, so packaging tools could use "site.userinstdir" or something. Right now, if it's present, it's just some random entry on sys.path.

6 9