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
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
> > ambiguous
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 f
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 setuptool
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
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 non
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 packa
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'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 c
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.
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
At 10:14 PM 4/18/2006 -0700, Neal Norwitz wrote:
>On 4/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
> > >who decided that setuptools should be added to 2.5, btw?
> >
> > Guido proposed it on Python-dev when the 2.5 schedule was first being
>
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, either.
>
> C
At 02:57 PM 4/19/2006 +1000, Anthony Baxter wrote:
>Sure, it's possible that some people with extremely complicated
>distutils scripts may find they need to update them.
...if and *only* if they want setuptools' features, or their users do.
Sorry to seize on this point out of context, Anthony. I
Travis Oliphant wrote:
> For what it's worth, NumPy also defines a data-type object which it
> uses to describe the fundamental data-type of an array. In the context
> of this thread it is also yet another way to describe a binary-packed
> structure in Python.
Maybe there should be a separat
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 modules like these have a solid history of use ou
On 4/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
> >who decided that setuptools should be added to 2.5, btw?
>
> Guido proposed it on Python-dev when the 2.5 schedule was first being
> discussed. I discussed it with him off-list, ...
I thou
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 don't have a problem at all with setuptools going into the standard
library. It adds a whole pile of extremely useful fun
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.
No, it wouldn't. There's no problem in
On 4/18/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > As for discussion, Guido originally brought up the question here a few
> > months ago, and it's been listed in PEP 356 for a while. I've also
> > posted things related to the inclusion both here and in distutils-sig.
At 02:12 AM 4/19/2006 +0200, Giovanni Bajo wrote:
>But, why can't setuptools be gradually merged into distutils, instead of being
>kept as a separate package? Let's take a real example: setuptools' sdist is
>much enhanced, has integration with CVS/SVN, uses MANIFEST in a way that it
>really works,
Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> > So, I'm not too pleased by insinuations that setuptools is
> anything other > than a Python community project.
>
> I've no doubt about that at all, FWIW. I think you've put a lot of
> effort into discussing it with the community, and applaud you
Giovanni Bajo wrote:
> tomer filiba <[EMAIL PROTECTED]> wrote:
>
>
>>the point is -- ctypes can define C types. not the TCP/IP stack.
>>Construct can do both. it's a superset of ctype's typing mechanism.
>>but of course both have the right to *coexist* --
>>ctypes is oriented at interop with dlls
At 07:08 PM 4/18/2006 -0400, Fred L. Drake, Jr. wrote:
>Saw that; hopefully I'll have a chance to look at it soon. I wonder,
>generally, if it should be merged into the distutils documentation. Those
>documents happen to be distutils-centric now, because that's what's been
>provided. Their title
At 12:49 AM 4/19/2006 +0200, Martin v. Löwis wrote:
>Fredrik Lundh wrote:
> > it's still listed under "possible additions" in the release PEP, and
> there don't
> > seem to be a PEP or any other easily located document that explains exactly
> > how it works, what's required from library developers
tomer filiba <[EMAIL PROTECTED]> wrote:
> the point is -- ctypes can define C types. not the TCP/IP stack.
> Construct can do both. it's a superset of ctype's typing mechanism.
> but of course both have the right to *coexist* --
> ctypes is oriented at interop with dlls, and provides the mechanism
On Tuesday 18 April 2006 19:00, Phillip J. Eby wrote:
> He then mentioned it in his 2.5 slideshow at PyCon. This is the first
> anyone's objected to it, however, at least that I'm aware of.
Until the past week, I wasn't aware it was being considered. But then, I've
not been paying a lot of at
At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
>who decided that setuptools should be added to 2.5, btw?
Guido proposed it on Python-dev when the 2.5 schedule was first being
discussed. I discussed it with him off-list, to ensure that it could be
done in a way that wouldn't interfere with ex
Fredrik Lundh wrote:
> it's still listed under "possible additions" in the release PEP, and there
> don't
> seem to be a PEP or any other easily located document that explains exactly
> how it works, what's required from library developers, how it affects existing
> toolchains, etc. is this reall
[EMAIL PROTECTED] wrote:
> Martin> Also, I suggest to use None as the return value for "no value
> Martin> available"; it might be that the configured value is an empty
> Martin> string (in which case confstr returns 1).
>
> I'll work on all of this. Are you sure you want the API to c
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> isn't the latter more elegant?
According to my experience with Python, as well as my interpretations of
the zens, no. -1
> and the zen supports my point:
> (*) Beautiful is better than ugly --> f(*(args + (7,))) is ugly
But explicit is better than imp
Phillip J. Eby wrote:
> Your proposals, however, generally favor experts at the expense of the
> average user, and treat it as axiomatic that the benefits provided by
> setuptools are not worth having, no matter how small the cost.
mal's arguing from well-established Python design principles (imp
> Consider it dead. =)
RIP. ;)
--
Gustavo Niemeyer
http://niemeyer.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-a
> Removing __metaclass__ in Python 3000
> -
>
> As a side-effect of its generality, the make-statement mostly
> eliminates the need for the ``__metaclass__`` attribute in class
> objects. Thus in Python 3000, instead of::
(...)
One of the reasons that this PEP
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 things in zip files, and older versions of
>
On 4/18/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> It is not yet too late (but the timeslot left is very small) to propose
> enhancements to ctypes. classmethods like 'from_string', 'from_buffer' or
> whatever would probably make sense.
A from_buffer classmethod would probably be good. I didn
i'm not going to defend and fight for this idea too much. i only bringit up because it bothers me. i'm sure some people here would kill me for
even suggesting this, and i really don't want to be killed right now,so i bring it up as something you should think about. nothing more.PEP-225 has some wei
ctypes, as the name implies, is relevant to *C data structures* only.you cannot extend it and you cannot define complex things with it, at least noteasily.
* ctypes doesn't have a way (that I'm aware of) to specify theendianness of types like c_short - so my example, when run on Windows(intel arch
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 easy to just remove th
Paul Moore wrote:
> On 4/17/06, tomer filiba <[EMAIL PROTECTED]> wrote:
>> after several people (several > 10) contacted me and said "IMHO 'construct'
>> is a good candidate for stdlib",
>> i thought i should give it a try. of course i'm not saying it should be
>> included right now, but in 6 month
At 04:18 PM 4/18/2006 -0400, A.M. Kuchling wrote:
>On Tue, Apr 18, 2006 at 08:55:18PM +0200, phillip.eby wrote:
> > Modified:
> >peps/trunk/pep-0343.txt
> >
> > +"context manager" then encompasses all objects with a __context__()
> > +method that returns a context object. (This means t
On 4/18/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I've updated PEP 359 with a bunch of the recent suggestions. The
> patch is available at:
> http://bugs.python.org/1472459
> and I've pasted the full text below.
>
> I've tried to be more explicit about the goals -- the make statement
> i
On 4/17/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> after several people (several > 10) contacted me and said "IMHO 'construct'
> is a good candidate for stdlib",
> i thought i should give it a try. of course i'm not saying it should be
> included right now, but in 6 months time, or such a
> time
"tomer filiba" <[EMAIL PROTECTED]> wrote in message
>* using lambda functions for meta expressions, instead of eval(string) --
>perhaps >it's faster, but lambda is getting deprecated by python3k :(
Good news for you then: Guido's latest thought that I have read is to leave
lambda alone, as is.
On Tue, Apr 18, 2006 at 08:55:18PM +0200, phillip.eby wrote:
> Modified:
>peps/trunk/pep-0343.txt
>
> +"context manager" then encompasses all objects with a __context__()
> +method that returns a context object. (This means that all contexts
> +are context managers, but not all con
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 that the tests ar
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 things in zip files, and older versions of
> pydoc don't work for packages zip files.
That doesn't ans
On 4/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I think we should correct the PEP.
Yes please, go ahead.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Definitely an intriguing idea! I am +0 just because I don't know how
needed it is, but it is definitely cool.
As for your open issues, ditching __metaclass__ is fine if this goes
in, but I would keep 'class' around as simplified syntactic sugar for
the common case.
-Brett
On 4/18/06, Steven Bet
On 4/18/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Brett,
>
> On Mon, Apr 17, 2006 at 05:34:16PM -0700, Brett Cannon wrote:
> > + if (meth == self) {
> > + PyErr_SetString(PyExc_RuntimeError,
> > + "recursive __call__ definition");
> > +
[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 ;-)
___
Python-Dev mailing list
Python-
M.-A. Lemburg wrote:
>I could contribute pybench to the Tools/ directory if that
>makes a difference:
>
>
>
+1 on adding pybench.
And we already have parrotbench in the sandbox.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On 4/18/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Anthony Baxter wrote:
> > On Thursday 06 April 2006 04:10, Benji York wrote:
> >> On a related note: it might be nice to put a pystone run in the
> >> buildbot so it'd be easier to compare pystones across different
> >> releases, different arch
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 things in zip files, and older versions of
pydoc don't work for packages zip files.
>If you want to provide a hot fix for Python 2.3
Anthony Baxter wrote:
> On Thursday 06 April 2006 04:10, Benji York wrote:
>> On a related note: it might be nice to put a pystone run in the
>> buildbot so it'd be easier to compare pystones across different
>> releases, different architectures, and between particular changes
>> to the code. (That
Phillip J. Eby wrote:
> At 10:55 AM 4/18/2006 +0200, M.-A. Lemburg wrote:
>> Phillip.eby wrote:
>> > Author: phillip.eby
>> > Date: Tue Apr 18 02:59:55 2006
>> > New Revision: 45510
>> >
>> > Modified:
>> >python/trunk/Lib/pkgutil.py
>> >python/trunk/Lib/pydoc.py
>> > Log:
>> > Second phase
I've updated PEP 359 with a bunch of the recent suggestions. The
patch is available at:
http://bugs.python.org/1472459
and I've pasted the full text below.
I've tried to be more explicit about the goals -- the make statement
is mostly syntactic sugar for::
class :
__metaclass__ =
Now that setuptools is in the trunk, I need to also add its manuals and the
source for its .exe files. These currently live only in the sandbox.
First, the C source, used to create the 'gui.exe' and 'cli.exe' launchers
that setuptools uses to create script wrappers on Windows. The source
curr
At 10:04 AM 4/18/2006 -0400, A.M. Kuchling wrote:
>PEP 343 says:
>
> 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 term
> "context" t
At 10:55 AM 4/18/2006 +0200, M.-A. Lemburg wrote:
>Phillip.eby wrote:
> > Author: phillip.eby
> > Date: Tue Apr 18 02:59:55 2006
> > New Revision: 45510
> >
> > Modified:
> >python/trunk/Lib/pkgutil.py
> >python/trunk/Lib/pydoc.py
> > Log:
> > Second phase of refactoring for runpy, pkgutil,
Indeed, I wish I had known about this a year ago; it would have saved
me a lot of work. Of course it probably didn't exist a year ago... :(
well, yeah. many people need "parsing-abilities", but they resort to ad-hoc parsers using struct/some ad-hoc implementation of their own. there clearly is a
PEP 343 says:
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 term
"context" then encompasses all objects with a __context__() method
why include Construct?* the struct module is very nice, but very limited and non-pythonic as well
* pure python (no platform/security issues) IMHO this is a drawback. More on this below.
* lots of people need to parse and build binary data structures, it's not an esoteric library
* license: publi
Martin v. Löwis wrote:
> It can't be that simple. Python's stdout should indeed be inherited
> from cmd.exe, but that, in turn, should have obtained it from
> buildbot. So even though cmd.exe closes its handle, Python's handle
> should still be fine. If buildbot then closes the other end of the
>
Hi Brett,
On Mon, Apr 17, 2006 at 05:34:16PM -0700, Brett Cannon wrote:
> + if (meth == self) {
> + PyErr_SetString(PyExc_RuntimeError,
> + "recursive __call__ definition");
> + return NULL;
> + }
This is not the proper way, as
Phillip.eby wrote:
> Author: phillip.eby
> Date: Tue Apr 18 02:59:55 2006
> New Revision: 45510
>
> Modified:
>python/trunk/Lib/pkgutil.py
>python/trunk/Lib/pydoc.py
> Log:
> Second phase of refactoring for runpy, pkgutil, pydoc, and setuptools
> to share common PEP 302 support code, as de
66 matches
Mail list logo
