At 11:09 AM 11/22/2006 -0500, Ian Murdock wrote:
>The first question we have to answer is: What does it mean to "add
>Python to the LSB"? Is it enough to say that Python is present
>at a certain version and above, or do we need to do more than that
>(e.g., many distros ship numerous Python add-ons which apps
>may or may not rely on--do we need to specific some of these too)?
Just a suggestion, but one issue that I think needs addressing is the FHS
language that leads some Linux distros to believe that they should change
Python's normal installation layout (sometimes in bizarre ways) or that
they should remove and separately package different portions of the
standard library. Other vendors apparently also patch Python in various
ways to support their FHS-based theories of how Python should install
files. These changes are detrimental to compatibility.
Another issue is specifying dependencies. The existence of the Cheeseshop
as a central registry of Python project names has not been taken into
account in vendor packaging practices, for example. (Python 2.5 also
introduced the ability to install metadata alongside installed Python
packages, supporting runtime checking for package presence and versions.)
I don't know how closely these issues tie into what the LSB is tying to do,
as I've only observed these issues in the breach, where certain
distribution policies require e.g. that project names be replaced with
internal package names, demand separation of package data files from their
packages, or other procrustean chopping that makes mincemeat of any attempt
at multi-distribution compatibility for an application or multi-dependency
library. Some clarification at the LSB level of what is actually
considered standard for Python might perhaps be helpful in motivating
updates to some of these policies.
http://www.python.org/sf/411881 is a bug about removing use
of 'except:' in stdlib code. In many cases the intent is to catch
one particular exception such as ImportError or AttributeError,
but catching all exceptions can disguise other problems.
Should PEP 8 mention this issue? Here's some proposed text for
- When catching exceptions, mention specific exceptions
whenever possible instead of using a bare 'except:' clause.
For example, use::
platform_specific_module = None
A bare 'except:' clause will catch SystemExit and KeyboardInterrupt
exceptions, making it harder to interrupt a program with Control-C,
and can disguise other problems. If you want to catch all
exceptions that signal program errors, use 'except StandardError:'.
A good rule of thumb is that you should only use 'except:' if the
exception handler will be printing out or logging the traceback; at
least the user will be aware that an error has occurred.
my name is Lars Gustäbel (SF gustaebel). I contributed
tarfile.py to the Python standard library in January 2003 and
have been the maintainer since then. I have provided about 25
patches over the years, most of them fixes, some of them new
features and improvements. As a result, I am pretty familiar
with the Python development process.
If possible I would like to get developer privileges to be able
to work more actively on tarfile.py for a certain time.
I am currently implementing read-write POSIX.1-2001 pax format
support. Development is still in progress, but it is already
clear at this point, that it will be a complex change, which
will definitely require some maintenance once it is finished and
in day-to-day use. I would like to clean up the tarfile test
suite during this process as well. The introduction of the pax
format is important because it is the first tar specification
that puts an end to those annoying limitations of the "original"
tar format. It will become the default format for GNU tar some
I just noticed that PEP 328 (relative imports) is listed as an accepted PEP,
but not completed. Is this because there is still things to do for 2.6 and
2.7? Or did someone just forget to move it to the completed PEPs section of
the PEP index? If it is the former then PEP 362 will need to be moved.
I also noticed that there is no mention of removing import redirection to a
top-level module by having None in sys.modules. Was this for
backwards-compatibility issues, or was it just not thought of?
At Guido's suggestion, a new mailing list has been created named
Python-Ideas (http://mail.python.org/mailman/listinfo/python-ideas). This
list is meant as a place for speculative, pie-in-the-sky language design
ideas to be discussed and honed to the point of practically being a PEP
before being presented to python-dev or python-3000. This allows both
python-dev and python-3000 to focus more on implementation work or final
approval/denial of ideas instead of being flooded with long threads where
people discuss ideas that are too nebulous to be considered for inclusion
Like python-dev and python-3000, Python-Ideas requires you subscribe before
you can post, but there is no moderator approval required. If you are
interested in helping me out by being an administrator or moderator for the
list, please let me know.
Raymond Hettinger schrieb:
> If you can find some other design that doesn't depend on the ordering of
> co_names, that would be nice; otherwise, we're adding a permanent
> complication to the compiler and establishing a new invariant that would
> have to be maintained by everyone hoping to generate or hack bytecodes.
It wouldn't be a strict invariant, but instead, breaking it would mean
that the memory consumption goes up somewhat.
I'm experimenting with a patch for dictionary lookup caching, the
main idea being avoiding the lookup of a constant (co_names) in
a dictionary if the dictionary didn't change since last lookup.
Currently the cache is held in a structure that is parallel to
co_names (the LOAD_GLOBAL opcode uses oparg to access
the cache slot) and this is wasteful if there are co_names entries
that are not used for global lookups.
Probably I could act at the code object creation time to
sort names so that ones used by LOAD_GLOBAL are
at the beginning of co_names but this would require inspecting
and hacking the already generated opcode.
Another case that would IMO be worth optimizing is the
LOAD_ATTR lookup when it's done after a LOAD_GLOBAL
(I suspect that in many cases the element being searched will
be a module so caching would be simple to implement; for
general objects things are way more complex and I see no
simple solution for caching dictionary lookups).
My opinion is that it would be by far better to do this ordering
of co_names at compile time but I've no idea where to look
for trying to make such a change.
Can someone please point me in the right direction ?
Dear Python developers,
while the JVM is opened to support dynamically typed languages  I
wonder if the CPyVM could not show more openness to statically typed
languages? Hereby I don't think that much about arbitrary languages for
the CPyVM but sublanguages like RPython which are "static enough" to be
compilable into extension modules .
However creating C extension modules from Python code is not really the
standard way I do think Python source should be handled. Instead I think
about a more direct VM support like the JVM does, that provides opcodes
like iload, fstore etc. Besides this I don't expect one canonical
approach for these type information to be feeded into the CPyVM. There
are type inferencer like rtyper for PyPy, Psycos continous bytecode
monitoring and also other approaches are possible that use type
feedback. Finally optional type declarations are also an issue; however
I would like to see language design discussions being separated ( ->
Python 3000 ) and focus on general APIs for compiler extensions / plugs
that deal with type information ( the architecture ) and VM