I just installed TwistedSumo-2006-02-12 on x86_64, and noticed a problem.
It installs arch-dep stuff into
and arch-indep into
as it should. But:
from twisted.web import html
exceptions.ImportError: No module named web
I'm guessing that what's happening is that since there is an
<arch-dep>/twisted, we never find the module <arch-indep>/twisted/web. If
my analysis (guess) is correct, I think we have a problem with the module
"Travis E. Oliphant" <oliphant.travis(a)ieee.org> wrote:
> It is very important for many people to get access to memory with some
> description of how that memory should be interpreted as an array.
> Several Python packages could benefit if Python had some notion of an
> array interface that was at least supported in a duck-typing fashion.
Which packages? Which people? Which constituencies?
"Travis E. Oliphant" <oliphant.travis(a)ieee.org> also wrote:
> My big quest is to get PIL, PyVox, WxPython, PyOpenGL, and so forth to
> be able to use the same interface. Blessing the interface by
> including it in the Python core would help. I'm also just wanting
> people in py-dev to get the concept of an array interface on their
> radar, as discussions of new bytes types emerges.
I use PIL and numarray a lot. It would be nice if they used a common
array format so I would not need to convert back and forth. But I
survive quite well with the current arrangement.
Many other packages besides PIL and Numeric / numarray / Numpy are
involved here: byte, struct, ctypes, SWIG, PyTables, Psyco, PyPy, Pyrex,
etc. There are some major issues that need to be dealt with which I will
state concisely in an abstract way.
A data structure without an API and thorough documentation is useless.
Any proposal needs to include them from the very start.
How should Python interact with low level data? By "low level data" I
mean data as seen by C, C++, and FORTRAN as well as linear arrays of bytes.
What changes in Python would make the packages listed above easier to
write and use? Easier enough to write that the package owners would be
willing to give up control of part of their packages.
Does anyone know of any academic-type papers that have been written in
the last few years on these matters?
the definition of sys.executable is a bit unclear, something that has led to
incompatible use in deployed code.
the docstring for sys.executable says "pathname of this Python interpreter",
which can be interpreted as either
a) sys.executable points to the executable that was used to load the
Python interpreter library/dll.
this use is supported by the docstring and the implementation, and is quite
common in the wild. an application using this interpretation may
- call sys.executable to run another instance of itself
- extract data from resources embedded in (or attached to) sys.executable
- locate configuration data etc via os.path.dirname(sys.executable)
b) sys.executable points to a standard Python interpreter executable of
the same version, and having the same library, as the currently running
this use is supported by more strict interpretation of the word "interpreter"
(as an executable, rather than an implementation DLL), and is quite common
in the wild. an application using this interpretation may
- call sys.executable to run a Python script in the same environment as itself.
c) sys.executable points to the file containing the actual ("this") interpreter. I
haven't seen any code that assumes this, probably because no implementation
uses this interpretation...
for programs that are invoked via the standard interpreter, case (a) and (b) are of
the problem is when the interpreter library is embedded in some other application;
should sys.executable be set to the actual EXE used to start the program, or to
something else ? if it's set to something else, how can that application do the things
that's described under (a) ?
to fix this, I propose adding another sys variable; for example, let sys.executable
keep behaving like case (a) (which is how it's implemented today), and add a new
sys.python_executable for case (b). the latter can then be set to None if a proper
interpreter cannot be located.
1. Maybe there should be a more obvious way to spell "bytes()*N".
I went through "bytes(*N)" and "bytes('\0'*N)" before I realized
there was a memory-efficient way to do it.
1a. Likewise, slice-assignment nicely handles memmove(), but there's
2. Having a plural noun as a type name is awkward. I wish we could
call it "buffer" (which, conveniently, also tells you that it's
mutable, even if you don't know the word "mutable" :-). Alas.
3. I wrote a toy BytesIO class to go with the toy bytes object:
(I hope this isn't considered wiki abuse -- it seemed as worthy and
relevant as most of what's in there.)
While it may seem like going backwards, I actually have a legitimate reason
for getting rid of the current thread safety mechanism in runpy.run_module. It
appears Guido's doubts about the approach I used are entirely justified.
When the alter_sys flag is set, runpy.run_module pokes around a bit in the sys
module. Because one of the things it modifies is sys.modules (putting a
partially initialised module there), it currently uses the import lock to make
this tinkering thread-safe.
However, if you try using "-m test.regrtest" you'll notice that
test_threaded_import gets skipped because the import lock is held in the main
application script. This is *not* the case when invoking regrtest directly via
the filesystem - in that case, the runtime simply puts the partially
initialised __main__ module into sys.modules, and leaves it to the application
to decide whether or not that module is safe to import.
That's all well and good for regrtest.py, but any program that actually
spawned additional threads that attempted to import modules would likely see
deadlocks in very short order.
Removing the locking from run_module() makes it more like the PyRun C APIs -
it puts the extra module in sys.modules, but leaves it up to the invoking code
to decide whether or not to grab the import lock (or some other
synchronisation object) during execution. The import lock will still be held
while trying to *find* the requested module and the various optimisation
caches in sys are updated.
If I don't hear any objections, I'll switch SVN (along with PEP 338 and the
docs patch) to the new (non-thread-safe) semantics sometime this weekend.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I've posted this question on comp.lang.python, but nobody seems to
conclude it is a bad idea, so I post it here.
Basically, should staticmethods be made callable so that the following
would not raise an exception:
def foo(): pass
bar = foo()
There's workarounds, but it's really just about usability. staticmethod
could still return a descriptor, but additionnally callable. Is there
something I'm missing? Is it error-prone in any way?
Note that I'm not a big fan of static methods myself, but I understand
users expecting this work.
Microsoft has recently released their express version of the Visual C++.
Given that this version is free for everyone, wouldn't it make sense
to ship Python 2.5 compiled with this version ?!
I suppose this would make compiling extensions easier for people
who don't have a standard VC++ .NET installed.
Note: This is just a thought - I haven't looked into the consequences
of building with VC8 yet, e.g. from the list of pre-requisites,
it's possible that .NET 2.0 would become a requirement.
Professional Python Services directly from the Source (#1, Feb 27 2006)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
I've just noticed that (in 2.3.4) open() seems to accept
just about anything after the first character of the
Python 2.3.4 (#1, Jun 30 2004, 16:47:37)
[GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("DU", "rqwerty")
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |