Torsten Landschoff wrote:
Today I got the attached two mails. I wonder how this happens and how to
fix it. Is it correct that zip archives are supported in sys.path now?
Yes, see PEP 273.
In that case probably python-gtk needs fixing. Otherwise something in
python is wicked.
No, it is behaving acco
Matthias Klose wrote:
The default /etc/python2.3/site.py specifies "ascii" as a system
encoding. This causes errors if non-ascii characters are fed to
python programs unaware of i18n/l10n issues (eq. libglade-convert
script). Please make utf-8 (which is backwards compatible but will not
cause fatal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just adopted python-xlib, and am now looking for a sponsor.
python-xlib is a pure-Python implementation of the X11 protocol;
my updated package is at
http://www.dcl.hpi.uni-potsdam.de/debian/source/python-xlib_0.12-5.diff.gz
http://www.dcl.hpi.uni-p
Joe Wreschnig wrote:
> Which installs ugettext as '_' function into the __builtin__ namespace.
> That makes _ return Python 'unicode' objects, which is what programs
> should be using internally anyway.
>
> This is harder if you're trying to localize a module since then you
> don't want to screw w
Josselin Mouette wrote:
Apart from a typo and the FSF address, the changes are about which
packaging variants are mandated, recommending to provide only one
python-foo package for each module, except when depending applications
mandate another python version.
This way, we could enforce that poli
To what cost? How many gigabytes of mirror space and bandwidth are we
wasting with python2.X-libprout stuff nobody ever uses?
I don't know. What is the answer to this question? I wouldn't expect
it to be more than 1GiB per mirror, though, likely much less. On
i386, for example, the "useless" pyt
James A. Treacy wrote:
Let's use gramps(*) as an example and that the default python switches
to 2.4. A user upgrades python (leaving 2.3 on the system), gramps and
python-glade2 to python 2.4 versions but does not ugrade python-gnome2
(this works since python 2.3 is still installed). All the dep
Bob Tanner wrote:
Note also that in many cases, the package will be a single .egg *file*,
(analagous to a Java .jar file) rather than a directory, and files are
preferable to directories in most cases as they make Python import
processing faster.
I don't think Debian should use the egg struct
Phillip J. Eby wrote:
Yes, it's true, zipfile import processing is faster than normal import
processing; it is in fact one of the reasons zipfile imports were added
to Python, because the zip directories are cached. A zipfile import
lookup is a single dictionary lookup, whereas a directory imp
Ian Bicking wrote:
Maybe an easier way to understand this (at least my impression) is that
zip files are treated as read-only. Any directory on sys.path gets
scanned everytime a new module is imported. And you never know if
someone added something, so you do it all over again each time. A zi
M.-A. Lemburg wrote:
Doesn't the standard "python setup.py install" work with
eggified packages anymore (meaning that the package is
installed as normal site-packages package) ?
No. First, an eggified package tries to download ez_setup
first, i.e. it won't do the distutils setup(), but the easy
Phillip J. Eby wrote:
If you have many zipfiles on sys.path, all applications will suffer
from having to read the TOC of all those zipfiles, even if they need
none of them. OTOH, if you had packages inside site-python, the
contents of the unused packages is simply ignored.
I'm sorry, but this
Phillip J. Eby wrote:
This is simply not true. If you don't believe PEP 302 and site.py,
measure it for yourself. The *only* addition to startup is the time to
actually read the .pth file and append the entries to the list.
I did. strace shows that all zip files are loaded.
And how often do
Phillip J. Eby wrote:
Debian should provide the packages, but not as eggs.
For packages that only operate as eggs, and/or require their
dependencies as eggs, you are stating a contradiction in terms. Eggs
are not merely a distribution format, any more than Java .jar files are.
So I should
M.-A. Lemburg wrote:
The main argument for using ZIP imports is to easy
distribution of complete pure-Python packages, not
a performance gain.
Precisely. For this reason, python2x.zip is on sys.path,
allowing you to include the entire library (subset) in
a single file.
It may also be of conven
Bob Tanner wrote:
When I read the above, my knee-jerk reaction is: Where is the data to backup
this statement?
One could show strace outputs, and compare the number of system calls.
Compiling this into actual timing is difficult: you would have to trade
stat calls for read calls, and you would
Phillip J. Eby wrote:
The only thing that occurs to me as even a possibility would be some
kind of frequently-used system administration utility, like if you were
going to rewrite all the bash builtin commands as Python scripts.
This whole discussion is not about whether the start time actuall
Phillip J. Eby wrote:
Debian should provide the packages, but not as eggs.
For packages that only operate as eggs, and/or require their
dependencies as eggs, you are stating a contradiction in terms. Eggs
are not merely a distribution format, any more than Java .jar files are.
So I shoul
Phillip J. Eby wrote:
I find that surprising, since I only use CGI if I'm not concerned about
the start time. It's not like there aren't dozens of "long-running
process" solutions for Python web apps including mod_python, FastCGI,
SCGI, Twisted, and even ReadyExec, to fit almost every conceiva
As for terminology, you seem to suggest to use "distribution" where
Debian uses "package". So "Debian package" would become "Debian
distribution". This does not sound right, because "Debian distribution"
is the entire collection of packages that is released e.g. on a DVD-ROM.
I'll try to use "proj
Paul Moore wrote:
It's a long time ago, and back prior to PEP 302, but I believe that
the original version of the zipimport PEP (PEP 273 by Jim Ahlstrom)
included some timings based on the original patch. While this did show
slowdowns with compressed zip files, it showed distinct speedups with
*u
Phillip J. Eby wrote:
I was referring to how the distribution is *installed*. You don't use
things directly from a deb file, they have to be installed on the
system. When you install an egg, you must use one of the three forms,
or the system as a whole will not function.
That depends on whe
Phillip J. Eby wrote:
I try to use very long names for options that can have damaging effects
if used indiscriminately. A project that's installed the "old-fashioned
way" (which is what this does, apart from adding .egg-info) is hard to
uninstall and may overwrite other projects' files. So, i
Bob Tanner wrote:
Is there an agreement amongst the interested debian-python
developers/packagers that Debian must support .egg's?
Answering the -IF- will let us move forward to the HOW.
Terminology is really critical here. Eggs are a certain structure
of information: a meta-data system along
Joe Wreschnig wrote:
> 1. Stop compiling .pyo files, entirely (I'm hoping for little
> argument on this).
I agree.
> How?: compileall.py:57, -cfile = fullname +
> (__debug__ and 'c' or 'o') +cfile = fullname + 'c'
This is the wrong solution, though. If Python is
Martin Michlmayr wrote:
> I definitely agree we should listen to the Python community,
Well, my *personal* view is this: I agree that it is highly
desirable that the "python" package is the entire thing, with
all batteries included. I'm uncertain what to think about
offering systems that only have
Matthias Klose wrote:
> It would be interesting to qualify the "lot". Even the Windows installer
> allows you to install only parts of the complete package. And won't
> these people complain that the C compiler is missing, at least you did
> install the headers?
It's difficult to quantify. I could
Bruce Sass wrote:
>> /usr/bin/python provided by the "python" package. Right now it's 2.3.5.
>
> So it is arbitrary, as in there is no technical reason which makes 2.3.5
> most suitable.
That impression is incorrect. There was a technical reason when the
default was defined: it was the most recen
I've updated python-fam to the new policy, and am now looking
for a sponsor. The files are at
http://www.dcl.hpi.uni-potsdam.de/debian/source/python-fam_1.1.1.orig.tar.gz
http://www.dcl.hpi.uni-potsdam.de/debian/source/python-fam_1.1.1-2.diff.gz
http://www.dcl.hpi.uni-potsdam.de/debian/source/pyth
29 matches
Mail list logo
