So go ahead and tear this apart so that we can hopefully reach a
consensus that makes sense so that at least testing can easily be
done.
If I was developing an application and wanted to deal with two
different versions of the same library, I would simply make sure that
the version I
On Mar 25, 2009, at 5:25 AM, Antoine Pitrou wrote:
Paul Moore gmail.com> writes:
3. Setuptools, unfortunately, has divided the Python distribution
community quite badly.
Wait a little bit, and it's gonna be even worse, now that buildout
and pip seem
to become popular. For example, the Tu
On Mar 27, 2009, at 6:22 PM, P.J. Eby wrote:
At 10:22 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
Perhaps someone should start working on a tool called "FryingPan" to
create "Omelettes", ie. all eggs squashed into a single ZIP
file... ;-)
They're called baskets actually. ;-) There's no tool
On Mar 27, 2009, at 6:25 PM, P.J. Eby wrote:
At 03:06 PM 3/27/2009 -0500, Tarek Ziadé wrote:
They both aim at the
same goal besides a few differences, and they both rely
on a new metadata introduced by setuptools, wich is.
"install_requires". This new metadata extends the metadata.
describ
On Apr 18, 2009, at 1:08 PM, Mitchell L Model wrote:
Some library files, such as pdb.py, begin with
#!/usr/bin/env python
In various discussions regarding some issues I submitted I was told
that the decision had been made to call Python 3.x release
executables python3. (One of the co
A plural class name looks strange (I think it's the first time I see
one in
the CPython codebase). How about another name? (DistributionPool,
DistributionMap, WorkingSet etc.).
Sure, WorkingSet is nice, it's the name used in setuptools,
A WorkingSet and a DistributionDirectories (or whate
On Jun 30, 2009, at 4:46 PM, Tarek Ziadé wrote:
On Tue, Jun 30, 2009 at 10:06 PM, Scott David
Daniels wrote:
Tarek Ziadé wrote:
On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore
wrote:
[1] I'd actually like it if the PEP defined an uninstall command -
something like "python -m distutils.uninst
On Oct 10, 2009, at 2:17 PM, Brett Cannon wrote:
The one unfortunate thing about this proposal is how this is going
to mean I have to install a package potentially four times if I want
it available to all possible Python interpreters. Then again, the
chances of anyone beyond the people on
On Nov 12, 2009, at 11:57 AM, Jesse Noller wrote:
On Thu, Nov 12, 2009 at 2:38 PM, "Martin v. Löwis"
wrote:
I am not an expert, I am just another python learner. These are
just my
views on the state of the standard libraries and to
make them state-of-the-art..! ;)
If I understand correct
On Nov 13, 2009, at 6:23 PM, Greg Ewing wrote:
Martin v. Löwis wrote:
> Some of the Python maintainers have recently started objecting to
this
> setup, asking that the standard library should be split into
separate
> packages that are released and distributed independent of Python.
Other
+1 on having established Python idioms for these techniques.
While I don't know if there has ever been a formal definition of
monkey patch, the term monkey patch came from guerilla patch, which
came from two or more dynamic modifications to a class interfering
with each other. These modifica
"It has to do with the MACOSX_DEPLOYMENT_TARGET. If it's set to 10.4,
the
legacy version of setpgrp is used (with args), it it's 10.5, setpgrp
expects no arguments. It seems configure won't detect the difference."
http://bugs.python.org/issue1358
This issue was fixed for Python 2.5. As the issu
On Sep 4, 2008, at 8:10 AM, C. Titus Brown wrote:
I have to say I've never had problems with a stock install of Python
on
either Mac OS X or Windows (shockingly enough :). I think this is
good
advice for applications that rely on external libraries, but I just
don't see any problems with
On Oct 4, 2008, at 9:59 PM, Martin v. Löwis wrote:
Setuptools declares dependencies, but does not add a Python version
requirement,
like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/
)
with a new metadata called 'Requires Python'
Even if the problem is fixed in shor
14 matches
Mail list logo
