On Fri, May 2, 2008 at 12:30 PM, Pete <pfein(a)pobox.com> wrote:
> What's the proper way to spell "any version in the 3.0.x series" if a
> project has a 3.1.0beta3 release?
> Specifically, CherryPy has both 3.0.2 and 3.1.0beta3 releases. I'd like to
> depend on any 3.0.x
> I've tried both 'CherryPy < 3.1' and 'CherryPy < 3.1.0' in my
> install_requires, and both cause setuptools to pull 3.1.0beta3.
> I realize I can use 'CherryPy == 3.0.2' but that defeats the "any 3.0.x"
I find this surprising as well, but the answer is:
>>> import pkg_resources
>>> v = pkg_resources.parse_version
>>> v('3.1.0beta3') < v('3.1.0')
>>> v('3.1.0beta3') < v('3.1.0a0')
I wish it was "easier" to say "3.1.x" (as in any final sub-point
release in the 3 series) or "1.x" (as in any final version 1 release)
which didn't allow development, alpha, beta, candidate, etc. releases.
What's the proper way to spell "any version in the 3.0.x series" if a
project has a 3.1.0beta3 release?
Specifically, CherryPy has both 3.0.2 and 3.1.0beta3 releases. I'd
like to depend on any 3.0.x
I've tried both 'CherryPy < 3.1' and 'CherryPy < 3.1.0' in my
install_requires, and both cause setuptools to pull 3.1.0beta3.
I realize I can use 'CherryPy == 3.0.2' but that defeats the "any
[Apologies if this was discussed in the past, I did some searching but
couldn't find much, but then again my attention is spread a little too thing
Right now setuptools on Windows x64 with 64-bits Python 2.5 is (partially)
The error shown is:
Cannot find Python executable C:\Python25\python.exe
when running easy_install. The phrase comes from launcher.c which is
compiled via MingW to cli.exe and gui.exe. Both of these are present in the
setuptools repository and are 32-bits only for all I can determine (using
file). I have not thoroughly checked it yet (due to being written in Unix-C,
even though it's aimed at Windows), but my guess is it's using some API
calls which fail on 64-bits Windows. I see there's a mingw-64 toolkit on the
'net nowadays. Has anyone tried this yet? Is it indeed an API issue?
Furthermore, when creating an egg on Windows x64, it will create it with an
identifier of win32, even though C code in a project is compiled with an
AMD64 version of the compiler. For all I know 32-bits Windows systems will
also pull down this version of the egg when given the chance.
I guess this is due to Python 2.5 64 bit reporting win32 for sys.platform?
So don't we miss something to properly distinguish between 64 bits Windows
and 32 bits? Especially with x64 and Vista 64 on the market nowadays?
Thanks for any pointers/clues...
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Whoever undertakes to set himself up as judge in the field of truth
and knowledge is shipwrecked by the laughter of the Gods.
On 10:53 pm, steve(a)holdenweb.com wrote:
>>Unfortunately these answers aren't quite right. A "package" is
>>actually a directory containing an __init__.py file, and a
>>distribution is actually what you think of when you say "package" -- a
>>reusable package of Python code that you can, for example, get from
>>the Python package index.
The fact that the Python "package" index is a place where you get
"distributions" does seem a bit weird to me, but this is not necessarily
a problem that can be fixed. Ambiguity is part of human language.
Perhaps suggest transliterations of these terms for talking about python
in lojban? :)
>>1. A "module" shall henceforth be the name for either a foo.py file
>>(a single-file module), or a directory with an __init__.py in it (a
I have a less disruptive counterproposal. How about just starting to
refer to directories (or "folders", or zip entries) with '__init__.py'
in them as "package modules"? A package is-a module anyway.
>>2. A "package" shall henceforth be the name of the thing that is
>>currently called a "distribution".
I belive a multi-word term here would be similarly more memorable and
precise. A "package distribution" would include the more familiar term
while still being specific, consistent with the old terminology, and
correct. Using a qualifying word is probably a good idea in this
context anyway. I usually say "debian package", "RPM", "MSI", or
"tarball" unless I'm specifically talking about "packages for your
platform", almost always in the phrase, "please do not use distutils to
do a system install of Twisted, use the specific package for your
I do, however, agree with Steve emphatically on your original proposal.
Changing the terminology now will make billions upon billions of Python
web pages, modules (c.f.
twisted.python.modules.PythonModule.isPackage()) documents, and
searchable message archives obsolete, not to mention that 90% of the
community will probably ignore you and use the old terminology anyway,
creating more confusion than it eliminates.
On both linux & OS X, Setuptools installs all .py/.pyc files with mode
a+x (executable for all users). This occurs regardless of original
the permissions in the source tarball. Doing so breaks nosetests,
which by default refuses to import executable files for test-discovery
purposes as a safety measure.
This behavior is broken & dangerous.
I'm having a problem with easy_install and a library I just installed.
I have a Mac OS 10.5 (Leopard), and I used the SciPy SuperPack
installer (http://macinscience.org/?page_id=6) to install a whole
bunch of scientific packages, including matplotlib.
I then used easy_install to install Basemap, which is a "toolkit"
based on matplotlib. The usual instructions for Basemap have the
import statement like this:
from matplotlib.toolkits.basemap import Basemap
However, when I try this in Python, I get an ImportError.
This obviously has something to do with the path that Python uses to
find libraries, and I found an easy_install.pth file that looks like
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:];
p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egg
insert = p+len(new)
Any clues as to what is going on, and how I can fix the problem?
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Here's an experiment you can perform. Round up a Python programmer
and ask him the following three questions:
Q1. You type "import foo" and it works. What kind of thing is foo?
Q2. You go to the Python package index and download something named
"bar-1.0.0.tar.gz". What kind of thing is bar?
Q3. What is a "distribution"?
I'm willing to bet that you will get the following answers:
A1. foo is a module.
A2. bar is a package.
A3. A distribution is a version of Linux that comes with a lot of
Unfortunately these answers aren't quite right. A "package" is
actually a directory containing an __init__.py file, and a
distribution is actually what you think of when you say "package" --
a reusable package of Python code that you can, for example, get from
the Python package index.
Educational efforts such as the Python tutorial and the distutils
docs have not succeeded in training Python programmers to understand
the terminology for these things as used by the Python implementors,
so perhaps instead the implementors should start using the
terminology understood by the programmers:
1. A "module" shall henceforth be the name for either a foo.py file
(a single-file module), or a directory with an __init__.py in it (a
2. A "package" shall henceforth be the name of the thing that is
currently called a "distribution".
who doesn't mind stirring up trouble on occasion...