At 01:33 AM 4/19/2006 -0400, Barry Warsaw wrote:
On Wed, 2006-04-19 at 14:57 +1000, Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile, either.
Agreed. If
Phillip J. Eby [EMAIL PROTECTED] wrote:
If so, can't we have some kind of versioning
system?
We do: import setuptools. We could perhaps rename it to import
distutils2 if you prefer, but it would mean essentially the same
thing. :)
I believe the naming is important, though. I'd rather it
Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile, either.
If I'm not calling shared libraries from Python I can ignore ctypes. If
I'm not doing XML, I can
At 08:11 AM 4/19/2006 +0200, Giovanni Bajo wrote:
Then, about new commands. Why should I need to do import distutils2 to do,
eg, setup.py develop? This doesn't break backward compatibility.
The develop command uses the egg_info command. egg_info uses the
setuptools enhanced MANIFEST scheme.
Anthony Baxter wrote:
I started refactoring some of the ugliness out of the internals of
distutils last year, but was completely stymied by the demand that no
existing setup.py scripts be broken.
Instead of trying to fix distutils, maybe it would be better
to start afresh with a new package
Neal Norwitz wrote:
I was also working under the assumption that people would complain if
they didn't like something. What do people think should happen for
the Possible features section? Should I ask if there are any
objections to each item?
some discussion on python-dev for each
Phillip J. Eby wrote:
I was surprised that MAL didn't comment *then*, actually, and mistakenly
thought it meant that our last discussion on the distutils-sig (and my
attempts to deal with the problems) had been successful. Between that and
MvL's mild response to the explicit discussion of
On Wednesday 19 April 2006 16:22, Walter Dörwald wrote:
If I'm not calling shared libraries from Python I can ignore
ctypes. If I'm not doing XML, I can ignore elementtree. If I'm not
doing SQL I can ignore pysqlite and if I'm not interested in
profiling I can ignore cProfile. But setuptools
At 08:22 AM 4/19/2006 +0200, Walter Dörwald wrote:
Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile, either.
If I'm not calling shared libraries from
Greg Ewing [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
One major problem with this is that except for function calls, * is the
multiplication operator, which operates on two arguments. *foo is an
operation on a single argument, and without parenthesis, would be
ambiguously parsed.
Phillip J. Eby wrote:
The long term plan is for a tool called nest to be offered, which will
offer a command-line interface similar to that of the yum package
manager, with commands to list, uninstall, upgrade, and perform other
management functions on installed packages.
yum already exists,
At 08:38 AM 4/19/2006 +0200, Fredrik Lundh wrote:
I'm -1 on adding tools to the core that changes the structure of an installed
Python system, without a full PEP process. If nobody can point to (or
produce)
a technical document that, in full detail, describes the mechanisms *used* by
setuptools,
Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile, either.
That's because they're all trivial building blocks, not all-consuming world
views. Any programmer
At 09:08 AM 4/19/2006 +0200, Fredrik Lundh wrote:
I've skimmed
the PEAK documentation, and all I find is bullet-point feature lists and
endless lists of configuration options. It's like reading Microsoft
documentation.
And I've read your email about the documentation, and all I find is
At 09:11 AM 4/19/2006 +0200, Walter Dörwald wrote:
With setuptools this doesn't work, because the package is distributed
over multiple egg-directories. AFAICR setuptools has a solution for this,
but only if the package __init__.py is empty (because setuptools
generates it). But I'd like to
Neal Norwitz wrote:
What are the doc plans for these modules:
+ * ctypes
+ * ElementTree/cElementTree
+ * msilib
+ * pysqlite
pysqlite: I've started on new module docs for the sqlite3 module in
the Python standard library, based on the text from the existing
pysqlite
Neal Norwitz wrote:
On 4/18/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-04-19 at 14:57 +1000, Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile,
M.-A. Lemburg wrote:
Tim Peters wrote:
[M.-A. Lemburg]
I could contribute pybench to the Tools/ directory if that
makes a difference:
+1. It's frequently used and nice work. Besides, then we could
easily fiddle the tests to make Python look better ;-)
That's a good argument :-)
Note
Giovanni Bajo: Both ctypes and construct provide a way to describe a binary-packed structure in Python terms: and this is an overload of functionalityso does struct, so why not just use struct? there's a receipe at the python
cookbook that adds naming ability to fields, i.e.6s.destincation
Phillip J. Eby wrote:
At 09:11 AM 4/19/2006 +0200, Walter Dörwald wrote:
With setuptools this doesn't work, because the package is distributed
over multiple egg-directories. AFAICR setuptools has a solution for
this, but only if the package __init__.py is empty (because setuptools
generates
A.M. Kuchling wrote:
On Tue, Apr 18, 2006 at 03:37:37PM -0400, Phillip J. Eby wrote:
I was going to say, so they can be context managers, but I suppose you
have a point. There is no need for a context to have a __context__ method,
unless it is also a context manager. Ugh.
It would be
On Tue, Apr 18, 2006 at 09:10:20PM -0700, Neal Norwitz wrote:
There is an outstanding issues section in the 2.5 release PEP 356. In
this case, perhaps it would have been good to add a bullet item there.
I've been trying to ensure the issues aren't lost. There's only one
item in the list that
On Wed, Apr 19, 2006 at 10:54:09AM +0200, Gerhard Häring wrote:
We should probably check my docs in soon even in a preliminary state, so
they can be reviewed/improved.
There's a group of volunteers who will help fix the LaTeX markup, so
you certainly don't need to have everything working (or
On Wed, Apr 19, 2006 at 10:00:21PM +1000, Nick Coghlan wrote:
And the parenthetical comment was completely backwards and should have read:
(This means that all context managers are contexts, but not all contexts
are
context managers).
The reason for recommending that context
Nick Coghlan wrote:
The second occurrence of context manager is meant to say context:
This PEP proposes that the protocol used by the with statement be
known as the context management protocol, and that objects that
implement that protocol be known as context managers. The
On Wed, Apr 19, 2006 at 11:10:55PM +1000, Nick Coghlan wrote:
When Phillip went through to make the terminology consistent he actually
swapped the meanings of context (which meant 'has a __context__ method'
in the original PEP) and context manager (which meant 'has __enter__ and
__exit__
A.M. Kuchling wrote:
On Wed, Apr 19, 2006 at 11:10:55PM +1000, Nick Coghlan wrote:
When Phillip went through to make the terminology consistent he actually
swapped the meanings of context (which meant 'has a __context__ method'
in the original PEP) and context manager (which meant 'has
At 11:10 PM 4/19/2006 +1000, Nick Coghlan wrote:
Ah, all is explained by svn blame, with a little help from svn log.
When Phillip went through to make the terminology consistent he actually
swapped the meanings of context (which meant 'has a __context__ method' in
the original PEP)
At least AMK
At 11:41 PM 4/19/2006 +1000, Nick Coghlan wrote:
Given that naming though, I think contextlib.contextmanager should be renamed
to contextlib.context.
The name is actually correct under this terminology
arrangement. @contextmanager *returns* a context manager. It happens to
also be a context,
On Wed, 2006-04-19 at 02:06 -0400, Phillip J. Eby wrote:
I agree. My one stupid nit is that I don't like the name
'easy_install'. I wish a better, non-underscored word could be found.
The long term plan is for a tool called nest to be offered, which will
offer a command-line interface
On Wed, 2006-04-19 at 18:26 +1200, Greg Ewing wrote:
I'd like to see a different approach taken to the design
altogether, something more along the lines of Scons.
Maybe it could even be an extension of Scons.
As much as I like Scons, there's too much unpythonic magic going on
there that I
M.-A. Lemburg wrote:
M.-A. Lemburg wrote:
Tim Peters wrote:
[M.-A. Lemburg]
I could contribute pybench to the Tools/ directory if that
makes a difference:
+1. It's frequently used and nice work. Besides, then we could
easily fiddle the tests to make Python look better ;-)
That's a good
Gerhard Häring wrote:
Speaking of which, what about SVN commit privileges for me?
Send me your key, and I'll add you. I assume 'gerhard.haering'
would work as the commit name?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Greg Ewing wrote:
I started refactoring some of the ugliness out of the internals of
distutils last year, but was completely stymied by the demand that no
existing setup.py scripts be broken.
Instead of trying to fix distutils, maybe it would be better
to start afresh with a new package
On 18-apr-2006, at 23:10, Phillip J. Eby wrote:
There aren't all that many things that are wrong in setuptools,
but some of them are essential:
* setuptools should not monkey patch distutils on import
Please propose an alternative, or better still, produce a patch.
Be sure
that it
[removing the python-checkins CC]
Phillip J. Eby wrote:
At 09:02 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Why should a 3rd party extension be hot-fixing the standard
Python distribution ?
Because setuptools installs
overriding __getattr__ and __setattr__ has several negative side effects, for example:* inside__getattr__/__setattr__ you have to use self.__dict__[attr] instead of
self.attr* it's easy to get stack overflow exceptions when you do something wrong
* you must remember to call the super's
At 07:46 PM 4/19/2006 +0200, Martin v. Löwis wrote:
Greg Ewing wrote:
I started refactoring some of the ugliness out of the internals of
distutils last year, but was completely stymied by the demand that no
existing setup.py scripts be broken.
Instead of trying to fix distutils, maybe it
At 08:33 PM 4/19/2006 +0200, Ronald Oussoren wrote:
Have you considered such a merger? It's rather odd to include a
package in
the stdlib that monkeypatches another part of the stdlib.
I assumed that it would be more controversial to merge setuptools into
distutils, than to provide it as an
At 08:45 PM 4/19/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 09:02 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Why should a 3rd party extension be hot-fixing the standard
Python distribution ?
Because
Martin v. Löwis wrote:
It is *precisely* my concern that this happens. For whatever reason,
writing packaging-and-deployment software is totally unsexy.
for some reason, tools of this kind tend to reach the big ball of mud stage
even before they reach the dogfood stage. and once you have a
Fredrik for some reason, tools of this kind tend to reach the big ball
Fredrik of mud stage even before they reach the dogfood stage. and
Fredrik once you have a big ball of mud, you simply won't get much
Fredrik outside help
Not to mention many dogs won't eat mud...
Skip
On Wed, Apr 19, 2006 at 03:02:15PM -0400, Phillip J. Eby wrote:
I can tell you the reasons, no need to guess:
5. The Distutils has lots of customization hooks, but if the exact
hook you need isn't there, you're in deep trouble. I learned this
when trying to implement a package database.
I
At 04:15 PM 4/19/2006 -0400, A.M. Kuchling wrote:
At least some of these changes to Distutils seem unobjectionable for
inclusion.
For example, the changes to Command just allow keyword arguments on
two methods and adds a class attribute; they seem unlikely to break
any existing users of the
On Apr 19, 2006, at 3:19 PM, Phillip J. Eby wrote:
At 08:45 PM 4/19/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 09:02 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Why should a 3rd party extension be
Phillip J. Eby wrote:
a technical document that, in full detail, describes the mechanisms *used* by
setuptools, including what files it creates, what the files contain, how
they are used during import, how non-setuptools code can manipulate (or at
least inpect) the data, etc, setuptools
At 11:36 PM 4/19/2006 +0200, Fredrik Lundh wrote:
Phillip J. Eby wrote:
a technical document that, in full detail, describes the mechanisms
*used* by
setuptools, including what files it creates, what the files contain, how
they are used during import, how non-setuptools code can
M.-A. Lemburg [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
FWIW: The docs are currently in the README file in Tools/pybench.
I took a look. The only thing that puzzles me is 'warp factor', which
appears exactly once.
tjr
___
On Thursday 20 April 2006 03:46, Martin v. Löwis wrote:
It is *precisely* my concern that this happens. For whatever
reason, writing packaging-and-deployment software is totally
unsexy. This is why setuptools is a one-man show, and this is why
the original distutils authors ran away after they
Martin v. Löwis wrote:
If distutils is now abandoned and replaced with
something else, the same story will happen again: the developers will
run away, the package gets abandoned,
Seems to me that if we had something with a clean
design that was easy to understand, maintain and
extend, that
On Thursday 20 April 2006 06:08, [EMAIL PROTECTED] wrote:
Fredrik for some reason, tools of this kind tend to reach the
big ball Fredrik of mud stage even before they reach the dogfood
stage. and Fredrik once you have a big ball of mud, you simply
won't get much Fredrik outside help
Not
At 10:39 AM 4/20/2006 +1000, Anthony Baxter wrote:
On Thursday 20 April 2006 03:46, Martin v. Löwis wrote:
It is *precisely* my concern that this happens. For whatever
reason, writing packaging-and-deployment software is totally
unsexy. This is why setuptools is a one-man show, and this is
On 4/18/06, Greg Ewing [EMAIL PROTECTED] wrote:
No, it wouldn't. There's no problem in giving an operator
different unary and binary meanings; '-' already does
that.
However unlike -, there is a two character ** operator, so while x--y
is the same as x - - y, x**y would not be the same as x *
On 4/19/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
People blame setuptools when pydoc doesn't work on packages in zip
files. Rather than refer to some theoretical argument why it's not my
fault and I shouldn't be the one to fix it, I prefer to fix the problem.
So rather than extract the zip
Anthony Baxter wrote:
http://www.joelonsoftware.com/articles/fog69.html
Yes. I remember that piece. In particular, he wrote the original rant
about this about Mozilla/Firefox. How did that work out again? Oh,
that's right - we now have a much, much more successful and usable
At 10:08 PM 4/19/2006 -0500, Michael Urman wrote:
On 4/19/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
People blame setuptools when pydoc doesn't work on packages in zip
files. Rather than refer to some theoretical argument why it's not my
fault and I shouldn't be the one to fix it, I prefer
On Thursday 20 April 2006 14:18, Fredrik Lundh wrote:
Anthony Baxter wrote:
http://www.joelonsoftware.com/articles/fog69.html
Yes. I remember that piece. In particular, he wrote the original
rant about this about Mozilla/Firefox. How did that work out
again? Oh, that's right -
In an attempt to help this thread reach some sort of resolution,
here's a collection of arguments against and in favour of setuptools
in 2.5. My conclusions are at the end.
The arguments against:
- Someone should instead just fix distutils.
Right. And the amount of yelling if distutils
Anthony Baxter wrote:
- Multiple installs of different versions of the same package,
including per-user installs.
yeah, but where is the documentation on how this works ? phillip points
to a 30-page API description, which says absolutely nothing whatsoever
about the files I'm going to find on
Anthony Baxter wrote:
It is *precisely* my concern that this happens. For whatever
reason, writing packaging-and-deployment software is totally
unsexy. This is why setuptools is a one-man show, and this is why
the original distutils authors ran away after they convinced
everybody that
Anthony Baxter wrote:
And I would reply that sometimes a rewrite is necessary. I doubt
firefox would be at the state it is today if it was still based on
the ancient netscape codebase.
It's off-topic here certainly: but firefox is actually not a complete
rewrite; it still has tons of
Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile, either.
I see a significant procedural difference between what happened
for ctypes, elementtree, and
62 matches
Mail list logo
