On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonough chr...@plope.com wrote:
All of these are really pretty minor issues compared with the main benefit
of not needing to ship everything with everything else. The killer feature
is that developers can specify dependencies and users can have those
hi,
I got the error below during installing the libmobiledevice:
checking consistency of all components of *python development environment...
no*
configure: error:
Could not link test program to Python. Maybe the main Python library has
been
installed in some non-standard library path. If
Hi,
This mailing list is for the development *of* Python.
Development *with* Python should be discussed on the python-list mailing
list, or the comp.lang.python usenet group.
There will be many people there willing to answer your question...
2012/6/21 Van Gao gaof...@126.com
hi,
I got the
Hello.
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing
On 06/21/2012 05:57 AM, Nick Coghlan wrote:
On Thu, Jun 21, 2012 at 3:29 AM, PJ Ebyp...@telecommunity.com wrote:
On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlanncogh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrousolip...@pitrou.net
wrote:
Agreed, especially if the proven
On Thu, Jun 21, 2012 at 9:45 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonough chr...@plope.com wrote:
All of these are really pretty minor issues compared with the main
benefit
of not needing to ship everything with everything else. The killer
Hi,
when lib/python/site-packages/ is accessed via NFS, open/stat/access is very
expensive/slow.
A simple solution is to use an in memory directory search/hash, so I was
wondering if this has been concidered in the past, if not, and I come
with a working solution for Unix (at least
On Thu, Jun 21, 2012 at 01:17:01PM +0300, Daniel Braniss da...@cs.huji.ac.il
wrote:
when lib/python/site-packages/ is accessed via NFS, open/stat/access is very
expensive/slow.
A simple solution is to use an in memory directory search/hash, so I was
wondering if this has been concidered in
Due to an user error on my part I was not using os.readlink correctly.
Since links can be relative to their location I think it would make sense
to provide an os.path.resolve helper that automatically returns the
absolute path:
def resolve(filename):
try:
target =
On Thu, 21 Jun 2012 13:17:01 +0300
Daniel Braniss da...@cs.huji.ac.il wrote:
Hi,
when lib/python/site-packages/ is accessed via NFS, open/stat/access is very
expensive/slow.
A simple solution is to use an in memory directory search/hash, so I was
wondering if this has been concidered in
Am 21.06.2012 12:23, schrieb Armin Ronacher:
Due to an user error on my part I was not using os.readlink correctly.
Since links can be relative to their location I think it would make sense
to provide an os.path.resolve helper that automatically returns the
absolute path:
def
Hi,
Am 21.06.2012 12:23, schrieb Armin Ronacher:
Does the code handle a chain of absolute and relative symlinks
correctly, for example a relative symlink that points to another
relative symlink in a different directory that points to a file in a
third directry?
No, but that's a good point.
On Thu, 21 Jun 2012 11:10:44 -
Armin Ronacher armin.ronac...@active-4.com wrote:
Hi,
Am 21.06.2012 12:23, schrieb Armin Ronacher:
Does the code handle a chain of absolute and relative symlinks
correctly, for example a relative symlink that points to another
relative symlink in a
Am 21.06.2012 13:10, schrieb Armin Ronacher:
Hello Armin,
No, but that's a good point. It should attempt to resolve these in a loop
until it either loops too often (would have to check the POSIX spec for a
reasonable value) or until it terminates by finding an actual file or
directory.
The
On Thu, Jun 21, 2012 at 11:10:44AM -, Armin Ronacher
armin.ronac...@active-4.com wrote:
would have to check the POSIX spec for a
reasonable value
POSIX allows 8 links:
http://infohost.nmt.edu/~eweiss/222_book/222_book/0201433079/ch02lev1sec5.html
_POSIX_SYMLOOP_MAX - number of
-- Forwarded message -- (whoops from my phone)
On Jun 21, 2012 6:32 AM, Armin Ronacher armin.ronac...@active-4.com
wrote:
Due to an user error on my part I was not using os.readlink correctly.
Since links can be relative to their location I think it would make sense
to provide
On 06/21/2012 04:45 AM, Nick Coghlan wrote:
On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonoughchr...@plope.com wrote:
All of these are really pretty minor issues compared with the main benefit
of not needing to ship everything with everything else. The killer feature
is that developers can
On 6/21/12 11:08 AM, Dag Sverre Seljebotn wrote:
...
David Cournapeau's Bento project takes the opposite approach,
everything is explicit and without any magic.
http://cournape.github.com/Bento/
It had its 0.1.0 release a week ago.
Please, I don't want to reopen any discussions about Bento
On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau courn...@gmail.com wrote:
If specifying install dependencies is the killer feature of setuptools, why
can't we have a very simple module that adds the necessary 3 keywords to
record it, and let 3rd party tools deal with it as they wish ? That
On 6/20/12 2:53 PM, Nick Coghlan wrote:
On Wed, Jun 20, 2012 at 9:31 PM, Tarek Ziadéta...@ziade.org wrote:
Yeah maybe this subset could be left in 3.3
and we'd remove packaging-the-installer part (pysetup, commands, compilers)
I think it's a good idea !
OK, to turn this into a concrete
On 21 June 2012 12:48, Chris McDonough chr...@plope.com wrote:
On 06/21/2012 04:45 AM, Nick Coghlan wrote:
On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonoughchr...@plope.com
wrote:
All of these are really pretty minor issues compared with the main
benefit
of not needing to ship everything
On Thu, Jun 21, 2012 at 12:58 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau courn...@gmail.com
wrote:
If specifying install dependencies is the killer feature of setuptools,
why
can't we have a very simple module that adds the necessary 3
On Thu, Jun 21, 2012 at 9:48 PM, Chris McDonough chr...@plope.com wrote:
On 06/21/2012 04:45 AM, Nick Coghlan wrote:
And, like it or not, setuptools has a serious PR problem due to the
fact it monkeypatches the standard library, uses *.pth files to alter
sys.path for every installed
On Thu, Jun 21, 2012 at 10:19 PM, David Cournapeau courn...@gmail.com wrote:
On Thu, Jun 21, 2012 at 12:58 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau courn...@gmail.com
wrote:
If specifying install dependencies is the killer feature of
On 06/21/2012 01:56 PM, Tarek Ziadé wrote:
On 6/21/12 11:08 AM, Dag Sverre Seljebotn wrote:
...
David Cournapeau's Bento project takes the opposite approach,
everything is explicit and without any magic.
http://cournape.github.com/Bento/
It had its 0.1.0 release a week ago.
Please, I don't
On 06/21/2012 08:21 AM, Nick Coghlan wrote:
Installing a distribution will change behavior whether or not sys.path is
changed as a result. That's its purpose.
No it won't. An ordinary package will only change the behaviour of
Python applications that import a package by that name. Other
On Thu, Jun 21, 2012 at 9:26 PM, Christian Heimes li...@cheimes.de wrote:
BTW Is there a better way than raise OSError(errno.ELOOP,
os.strerror(errno.ELOOP), filename) to raise a correct OSError with
errno, errno message and filename? A classmethod like
OSError.from_errno(errno, filename=None)
On Thu, 21 Jun 2012 15:04:17 +0200
Christian Heimes li...@cheimes.de wrote:
How about adding keyword support to OSError and derive the strerror from
errno if the second argument is not given?
That's not the original behaviour:
Python 3.2.2+ (3.2:9ef20fbd340f, Oct 15 2011, 21:22:07)
[GCC
On 6/21/12 2:45 PM, Dag Sverre Seljebotn wrote:
Guido was asked about build issues and scientific software at PyData
this spring, and his take was that if scientific users have concerns
that are that special, perhaps you just need to go and do your own
thing. Which is what David is doing.
On Thu, Jun 21, 2012 at 10:51 PM, Chris McDonough chr...@plope.com wrote:
Is it reasonable to even assume there is only one-sys.path-to-rule-them-all?
And that users install the set of libraries they need into a common place?
This quickly turns into failure, because Python is used for many,
On Wed, Jun 20, 2012 at 11:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
Right - clearly enumerating the features that draw people to use
setuptools over just using distutils should be a key element in any
PEP for 3.4
I honestly think a big part of why packaging ended up being incomplete
Chris McDonough chrism at plope.com writes:
On 06/21/2012 04:45 AM, Nick Coghlan wrote:
A packaging PEP needs to explain:
- what needs to be done to eliminate any need for monkeypatching
- what's involved in making sure that *.pth are *not* needed by default
- making sure that executable
On Jun 21, 2012, at 07:48 AM, Chris McDonough wrote:
I don't know about Red Hat but both Ubuntu and Apple put all kinds of stuff
on the default sys.path of the system Python of the box that's related to
their software's concerns only. I don't understand why people accept this
but get crazy about
On Thu, Jun 21, 2012 at 11:31 PM, PJ Eby p...@telecommunity.com wrote:
So, if we are to draw any lesson from the past, it would seem to be, make
sure that the people who'll be doing the work are actually going to be
available through to the next Python version.
Thanks for that write-up - I
On Thu, 21 Jun 2012 13:17:01 +0300
Daniel Braniss da...@cs.huji.ac.il wrote:
Hi,
when lib/python/site-packages/ is accessed via NFS, open/stat/access is very
expensive/slow.
A simple solution is to use an in memory directory search/hash, so I was
wondering if this has been
Hi,
On 6/21/12 7:56 AM, Tarek Ziadé wrote:
On 6/21/12 11:08 AM, Dag Sverre Seljebotn wrote:
...
David Cournapeau's Bento project takes the opposite approach,
everything is explicit and without any magic.
http://cournape.github.com/Bento/
It had its 0.1.0 release a week ago.
Please, I don't
On Jun 21, 2012, at 08:51 AM, Chris McDonough wrote:
The reason it's disappointing to see OS vendors mutating the default sys.path
is because they put *very old versions of very common non-stdlib packages*
(e.g. zope.interface, lxml) on sys.path by default. The path is tainted out
of the box for
On 06/21/2012 09:29 AM, Nick Coghlan wrote:
My only comment on that is this: Since this is a problem related to the
installation of Python distributions, it should deal with the problems that
Python developers have more forcefully than non-Python developers and
non-programmers.
Thanks to venv,
On Thu, Jun 21, 2012 at 11:57 PM, Barry Warsaw ba...@python.org wrote:
On Jun 21, 2012, at 07:48 AM, Chris McDonough wrote:
I don't know about Red Hat but both Ubuntu and Apple put all kinds of stuff
on the default sys.path of the system Python of the box that's related to
their software's
On Thu, Jun 21, 2012 at 11:16 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 21 Jun 2012 15:04:17 +0200
Christian Heimes li...@cheimes.de wrote:
How about adding keyword support to OSError and derive the strerror from
errno if the second argument is not given?
That's not the original
On Thu, 21 Jun 2012 17:08:09 +0300
Daniel Braniss da...@cs.huji.ac.il wrote:
There is such a thing in Python 3.3, although some stat() calls are
still necessary to know whether the directory caches are fresh.
Can you give it a try and provide some feedback?
WOW!
with a sample python
On 06/21/2012 03:23 PM, Tarek Ziadé wrote:
On 6/21/12 2:45 PM, Dag Sverre Seljebotn wrote:
Guido was asked about build issues and scientific software at PyData
this spring, and his take was that if scientific users have concerns
that are that special, perhaps you just need to go and do your
On Fri, Jun 22, 2012 at 12:12 AM, Chris McDonough chr...@plope.com wrote:
On 06/21/2012 09:29 AM, Nick Coghlan wrote:
My only comment on that is this: Since this is a problem related to the
installation of Python distributions, it should deal with the problems
that
Python developers have
On 2012-06-21 06:23, Armin Ronacher wrote:
Due to an user error on my part I was not using os.readlink correctly.
Since links can be relative to their location I think it would make sense
to provide an os.path.resolve helper that automatically returns the
absolute path:
def
On Thu, 21 Jun 2012 10:23:25 -
Armin Ronacher armin.ronac...@active-4.com wrote:
Due to an user error on my part I was not using os.readlink correctly.
Since links can be relative to their location I think it would make sense
to provide an os.path.resolve helper that automatically returns
On 06/21/2012 10:30 AM, Nick Coghlan wrote:
A tool to generate an OS-specific system package from a Python library
project should be unrelated to a Python distribution *installer*. Instead,
you'd use related tools that understood how to unpack the distribution
packaging format to build one or
On Thu, Jun 21, 2012 at 12:57 AM, Nick Coghlan ncogh...@gmail.com wrote:
Standard assumptions about the behaviour of site and distutils cease to be
valid once setuptools is installed
…
- advocacy for the egg format and the associated sys.path changes that
result for all Python programs
On Thu, 21 Jun 2012 12:02:58 -0300
Zooko Wilcox-O'Hearn zo...@zooko.com wrote:
Fortunately, this issue is fixable! I opened a bug report and I and a
others have provided patches that makes setuptools stop doing this
behavior. This makes the above documentation true again. The negative
impact
Nick Coghlan ncoghlan at gmail.com writes:
The Python community covers a broad spectrum of use cases, and I
suspect that's one of the big reasons packaging can get so contentious
- the goals end up being in direct conflict. Currently, I've
identified at least half a dozen significant
On Thu, Jun 21, 2012 at 2:44 AM, larry.hastings
python-check...@python.org wrote:
http://hg.python.org/peps/rev/1edf1cecae7d
changeset: 4472:1edf1cecae7d
user: Larry Hastings la...@hastings.org
date: Thu Jun 21 01:44:15 2012 -0700
summary:
The latest changes from Yury
On Jun 21, 2012 11:02 AM, Zooko Wilcox-Oapos;Hearn zo...@zooko.com
wrote:
Philip J. Eby provisionally approved of one of the patches, except for
some specific requirement that I didn't really understand how to fix
and that now I don't exactly remember:
On Jun 21, 2012 10:12 AM, Chris McDonough chr...@plope.com wrote:
- Install package resources, which are non-Python source files that
happen to live in package directories.
I love this phrasing, by the way (non-Python source files).
A pet peeve of mine is the insistence by some people that
On Fri, Jun 22, 2012 at 12:59 AM, Chris McDonough chr...@plope.com wrote:
On 06/21/2012 10:30 AM, Nick Coghlan wrote:
That will give at least 3 mechanisms for Python code to get onto a system:
1. Python dist - converter - system package - system Python path
2. Python dist - system Python
On 06/21/2012 11:37 AM, PJ Eby wrote:
On Jun 21, 2012 11:02 AM, Zooko Wilcox-Oapos;Hearn zo...@zooko.com
mailto:zo...@zooko.com wrote:
Philip J. Eby provisionally approved of one of the patches, except for
some specific requirement that I didn't really understand how to fix
and that now
On 06/21/2012 11:45 AM, PJ Eby wrote:
On Jun 21, 2012 10:12 AM, Chris McDonough chr...@plope.com
mailto:chr...@plope.com wrote:
- Install package resources, which are non-Python source files that
happen to live in package directories.
I love this phrasing, by the way (non-Python source
On 6/21/12 5:50 PM, Chris McDonough wrote:
A minor backwards incompat here to fix that issue would be
appropriate, if only to be able to say hey, that issue no longer
exists to folks who condemn the entire ecosystem based on that bug.
At least, that is, if there will be another release of
On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough chr...@plope.com wrote:
On 06/21/2012 11:37 AM, PJ Eby wrote:
On Jun 21, 2012 11:02 AM, Zooko Wilcox-Oapos;Hearn zo...@zooko.com
mailto:zo...@zooko.com wrote:
Philip J. Eby provisionally approved of one of the patches, except for
On 06/21/2012 12:26 PM, PJ Eby wrote:
On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough chr...@plope.com
mailto:chr...@plope.com wrote:
On 06/21/2012 11:37 AM, PJ Eby wrote:
On Jun 21, 2012 11:02 AM, Zooko Wilcox-Oapos;Hearn
zo...@zooko.com mailto:zo...@zooko.com
On 6/21/12 6:44 PM, Chris McDonough wrote:
Yes. At the very least, there will be updated development snapshots
(which are what buildout uses anyway).
(Official releases are in a bit of a weird holding pattern.
distribute's versioning scheme leads to potential confusion: if I
release e.g.
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. Signature Parameter objects are now immutable
2. Signature.replace() and Parameter.replace()
3. Signature has a new default constructor, which
accepts parameters list and a
On 2012-06-21, at 11:34 AM, Eric Snow wrote:
On Thu, Jun 21, 2012 at 2:44 AM, larry.hastings
python-check...@python.org wrote:
http://hg.python.org/peps/rev/1edf1cecae7d
changeset: 4472:1edf1cecae7d
user:Larry Hastings la...@hastings.org
date:Thu Jun 21 01:44:15 2012 -0700
Hi,
On 6/21/12 1:20 PM, Tarek Ziadé wrote:
On 6/21/12 6:44 PM, Chris McDonough wrote:
Yes. At the very least, there will be updated development snapshots
(which are what buildout uses anyway).
(Official releases are in a bit of a weird holding pattern.
distribute's versioning scheme leads
On Thu, Jun 21, 2012 at 1:20 PM, Tarek Ziadé ta...@ziade.org wrote:
telling us no one that is willing to maintain setuptools is able to do so.
(according to him)
Perhaps there is some confusion or language barrier here: what I said at
that time was that the only people who I already *knew* to
On 06/21/2012 01:20 PM, Tarek Ziadé wrote:
On 6/21/12 6:44 PM, Chris McDonough wrote:
Yes. At the very least, there will be updated development snapshots
(which are what buildout uses anyway).
(Official releases are in a bit of a weird holding pattern.
distribute's versioning scheme leads
On Thu, Jun 21, 2012 at 10:08 AM, Daniel Braniss da...@cs.huji.ac.ilwrote:
On Thu, 21 Jun 2012 13:17:01 +0300
Daniel Braniss da...@cs.huji.ac.il wrote:
Hi,
when lib/python/site-packages/ is accessed via NFS, open/stat/access
is very
expensive/slow.
A simple solution is to use
On 6/21/12 7:49 PM, PJ Eby wrote:
On Thu, Jun 21, 2012 at 1:20 PM, Tarek Ziadé ta...@ziade.org
mailto:ta...@ziade.org wrote:
telling us no one that is willing to maintain setuptools is able
to do so. (according to him)
Perhaps there is some confusion or language barrier here: what I
On 6/21/12 4:26 PM, Dag Sverre Seljebotn wrote:
project should give me so I can compile its extensions ? I think this
has nothing to do with the tools/implementations.
If you sit down and ask your self: what are the information a python
I'm not sure if I understand. A project can't give the
On 6/21/12 7:56 PM, Chris McDonough wrote:
...
think any API has been removed or modified.
In my opinion, distribute is the only project that should go forward
since it's actively maintained and does not suffer from the bus factor.
Yeah the biggest difference is Py3 compat, other than that
Can I take a step back and make a somewhat different point.
Developer requirements are very relevant, sure. But the most important
requirements are those of the end user. The person who simply wants to
*use* a distribution, couldn't care less how it was built, whether it
uses setuptools, or
On Thu, Jun 21, 2012 at 4:01 PM, Paul Moore p.f.mo...@gmail.com wrote:
End users should not need packaging tools on their machines.
Well, unless they're developers. ;-) Sometimes, the end user is a
developer making use of a library.
Development tools like distutils2, distribute/setuptools,
On 06/21/2012 09:05 PM, Tarek Ziadé wrote:
On 6/21/12 4:26 PM, Dag Sverre Seljebotn wrote:
project should give me so I can compile its extensions ? I think this
has nothing to do with the tools/implementations.
If you sit down and ask your self: what are the information a python
I'm not
On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote:
...
I think we should, as you proposed, list a few projects w/ compilation
needs -- from the simplest to the more complex, then see how a standard
*description* could be used by any tool
It's not clear to me what you mean by description. Package
On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote:
End users should not need packaging tools on their machines.
Sort of riffing on this idea, I cannot seem to find a specification for what a
Python
package actually is. Maybe the first effort should focus on this instead of
arguing one
On Thu, Jun 21, 2012 at 10:04 PM, Tarek Ziadé ta...@ziade.org wrote:
On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote:
...
I think we should, as you proposed, list a few projects w/ compilation
needs -- from the simplest to the more complex, then see how a standard
*description* could be
On Thu, 21 Jun 2012 22:46:58 +0200
Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no wrote:
The other thing is, the folks in distutils2 and myself, have zero
knowledge about compilers. That's why we got very frustrated not to see
people with that knowledge come and help us in this area.
On 06/21/2012 11:04 PM, Tarek Ziadé wrote:
On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote:
...
I think we should, as you proposed, list a few projects w/ compilation
needs -- from the simplest to the more complex, then see how a standard
*description* could be used by any tool
It's not clear
On Wed, Jun 20, 2012 at 11:54 AM, Brian Curtin br...@python.org wrote:
As the PEP czar for 397, after Martin's final updates, I hereby
pronounce this PEP accepted!
Thanks to Mark Hammond for kicking it off, Vinay Sajip for writing up
the code, Martin von Loewis for recent updates, and
On 06/22/2012 12:05 AM, Dag Sverre Seljebotn wrote:
On 06/21/2012 11:04 PM, Tarek Ziadé wrote:
On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote:
...
I think we should, as you proposed, list a few projects w/ compilation
needs -- from the simplest to the more complex, then see how a standard
On Thu, Jun 21, 2012 at 11:00 PM, Antoine Pitrou solip...@pitrou.netwrote:
On Thu, 21 Jun 2012 22:46:58 +0200
Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no wrote:
The other thing is, the folks in distutils2 and myself, have zero
knowledge about compilers. That's why we got very
On 6/21/12 11:55 PM, David Cournapeau wrote:
I think there is a misunderstanding of what bento is: bento is not a
compiler or anything like that. It is a set of libraries that work
together to configure, build and install a python project.
Concretely, in bento, there is
- a part that
Hi,
On 6/21/12 5:38 PM, Donald Stufft wrote:
On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote:
End users should not need packaging tools on their machines.
Sort of riffing on this idea, I cannot seem to find a specification for
what a Python
package actually is.
FWIW according to
On Thursday, June 21, 2012 at 7:34 PM, Alex Clark wrote:
Hi,
On 6/21/12 5:38 PM, Donald Stufft wrote:
On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote:
End users should not need packaging tools on their machines.
Sort of riffing on this idea, I cannot seem to find a
On 22/06/2012 8:14 AM, Brian Curtin wrote:
On Wed, Jun 20, 2012 at 11:54 AM, Brian Curtin br...@python.org wrote:
As the PEP czar for 397, after Martin's final updates, I hereby
pronounce this PEP accepted!
Thanks to Mark Hammond for kicking it off, Vinay Sajip for writing up
the code, Martin
Hello,
On behalf of Brett, Larry, and myself, I'm requesting for PEP 362
pronouncement.
The PEP, has been updated with all feedback from python-dev list
discussions. I'm posting the latest version of it with this message.
The PEP is also available here: http://www.python.org/dev/peps/pep-0362/
On Fri, Jun 22, 2012 at 10:01 AM, Donald Stufft donald.stu...@gmail.com wrote:
The idea i'm hoping for is to stop worrying about one implementation over
another and
hoping to create a common format that all the tools can agree upon and
create/install.
Right, and this is where it encouraged me
On Fri, Jun 22, 2012 at 11:56 AM, Yury Selivanov
yselivanov...@gmail.com wrote:
Hello,
On behalf of Brett, Larry, and myself, I'm requesting for PEP 362
pronouncement.
The PEP, has been updated with all feedback from python-dev list
discussions. I'm posting the latest version of it with
On Friday, June 22, 2012 at 1:05 AM, Nick Coghlan wrote:
- I reject setup.cfg, as I believe ini-style configuration files are
not appropriate for a metadata format that needs to include file
listings and code fragments
- I reject bento.info (http://bento.info), as I think if we accept
87 matches
Mail list logo
