2009/3/21 Greg Ewing :
> P.J. Eby wrote:
>
>> My concern is that allowing 'return value' in generators is going to be
>> confusing, since it effectively causes the return value to "disappear" if
>> you're not using it in this special way with some framework that takes
>> advantage.
>
> But part of
2009/3/23 Chris Withers :
> Paul Moore wrote:
>>
>> I am not. What I *am* doing is saying (obliquely, I admit) is that for
>> a package management system to be "decent enough" for stripping down
>> the stdlib to not be an issue, it has to address these points
2009/3/25 Steve Holden :
> As far as memory serves, Mike built the installers precisely by using
> distutils to build Windows installers. He then had to suffer criticism
> from people who suggested this was inappropriately complex for pure
> Python modules.
>
> In so far as "end users" won't wish
2009/3/25 Tarek Ziadé :
> I can't hear that setuptools has divided the Python community. It has provided
> solutions to real problems we had in web development. It's unperfect,
> and it has to be
> fixed and integrated into Python. But it should not be done outside Python
> imho.
It's quite possi
2009/3/25 Tarek Ziadé :
>> People should really stop splitting their work into micro-libraries (with
>> such
>> ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of
>> separately-packaged plugins (the repoze stuff). The Twisted approach is much
>> saner, where you have a coh
2009/3/25 Tarek Ziadé :
> On Wed, Mar 25, 2009 at 3:08 PM, Paul Moore wrote:
>>
>> Hence my comment about "dividing the community". From my limited
>> perspective, it's about no longer having a standard Windows binary
>> distribution format used
2009/3/25 Terry Reedy :
> Is it possible to write an egg to bdist converter (or vice versa)?
No idea. But would it help? Distributors would still only provide one
or the other, so when only an egg is available, I'd still have to
convert it - which is certainly pretty simple, but so is python
setup
2009/3/26 Barry Warsaw :
> Let me clarify my position: I just want the functionality (preferably in the
> stdlib); I don't really care how it's spelled (except please not
> pkg_resource.whatever() :).
Agreed. My one major reservation is that conceptually, the whole
pkg_resource infrastructure seem
2009/3/27 Guido van Rossum :
> - keep distutils, but start deprecating certain higher-level
> functionality in it (e.g. bdist_rpm)
> - don't try to provide higher-level functionality in the stdlib, but
> instead let third party tools built on top of these core APIs compete
Please don't move bdist_
2009/3/27 Collin Winter :
> In particular, Windows support is one of those things we'll need to
> address on our end. LLVM's Windows support may be spotty, or there may
> be other Windows issues we inadvertently introduce. None of the three
> of us have Windows machines, nor do we particularly want
2009/3/27 Jesse Noller :
> That's because most of us who might like this have been patently
> avoiding this thread.
>
> I like the syntax, I'm iffy on the exception other than stop iteration
> (but I lost track on what was decided on this) and I would like to see
> this go in. I think this is going
2009/3/27 David Cournapeau :
> Concerning contribution for windows binaries: as the current numpy
> developer in charge of windows binaries and windows support for a
> while, my experience is that the windows situation for contribution is
> very different from the other platforms. The mentality is
2009/3/27 Thomas Wouters :
> It's not a matter of chipping away support. It's a matter of wishing to not
> write our own JIT, but rather leverage other people's work. That currently
> means LLVM, but LLVM has a weak Windows story at the moment.
Ah, I see. That's much more encouraging. On the other
2009/4/1 Tres Seaver :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Stephen J. Turnbull wrote:
>
>> I also just wrote a long post about the comparison of bzr to hg
>> responding to a comment on baz...@canonical.com. I won't recap it
>> here but it might be of interest.
>
> Thank you very
2009/4/3 Ulrich Eckhardt :
> Hi!
>
> I just stumbled across something in Python 2.6 where I'm not sure if it is by
> design or a fault:
>
> x = 'abdc'
> x[-3:-3] -> ''
> x[-3:-2] -> 'b'
> x[-3:-1] -> 'bc'
> x[-3: 0] -> ''
>
> The one that actually bothers me here is the last one, I would have expec
2009/4/3 Hrvoje Niksic :
> I've stumbled upon an oddity using sets. It's trivial to test if a value is
> in the set, but it appears to be impossible to retrieve a stored value,
> other than by iterating over the whole set. Let me describe a concrete use
> case.
>
> Imagine a set of objects identi
2009/4/3 Steven D'Aprano :
> Python does not promise that if x == y, you can use y anywhere you can
> use x. Nor should it. Paul's declaration of abuse of __eq__ is
> unfounded.
Sorry, I was trying to simplify what I was saying, and simplified it
to the point where it didn't make sense :-) Martin
2009/4/3 R. David Murray :
> a == b
>
> So, python calls a.__eq__(b)
>
> Now, that function does:
>
> a.key == b
>
> Since b is an object with an __eq__ method, python calls
> b.__eq__(a.key).
That's the bit I can't actually find documented anywhere.
Ah, looking again I see that I misread the sec
2009/4/7 Cesare Di Mauro :
> The principle that I followed on doing constant folding was: "do what Python
> will do without constant folding enabled".
>
> So if Python will generate
>
> LOAD_CONST 1
> LOAD_CONST 2
> BINARY_ADD
>
> the constant folding code will simply replace them with a
It would have helped if I'd copied the list...
Sorry,
Paul.
2009/4/7 Paul Moore :
> 2009/4/7 Michael Foord :
>> Mark Dickinson wrote:
>>>
>>> [snip...]
>>> Discussion points
>>> =
>>>
>>> (1) Any objections to
2009/4/8 Duncan Booth :
> Andrea Griffini wrote:
>
>> On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich
>> wrote:
>>> You wrote a program to find the two smallest ints that would have a
>>> hash collision in the CPython set implementation? I'm impressed.
>>> And by impressed I mean frightened.
>>
2009/4/8 Steve Holden :
> Paul Moore wrote:
>> 2009/4/8 Duncan Booth :
>>> Andrea Griffini wrote:
>>>
>>>> On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich
>>>> wrote:
>>>>> You wrote a program to find the two smallest ints that w
2009/4/10 Nick Coghlan :
> gl...@divmod.com wrote:
>> On 03:21 am, ncogh...@gmail.com wrote:
>>> Given that json is a wire protocol, that sounds like the right approach
>>> for json as well. Once bytes-everywhere works, then a text API can be
>>> built on top of it, but it is difficult to build a b
2009/4/16 Jess Austin :
> I'm new to python core development, and I've been advised to write to
> python-dev concerning a feature/patch I've placed at
> http://bugs.python.org/issue5434, with Rietveld at
> http://codereview.appspot.com/25079.
>
> This patch adds a "monthdelta" class and a "monthmod
2009/4/16 :
> >>> date(2008, 1, 30) + monthdelta(1)
> datetime.date(2008, 2, 29)
>
> What would this loop would print?
>
> for d in range(1, 32):
> print date(2008, 1, d) + monthdelta(1)
>
> I have this funny feeling that arithmetic using monthdelta wouldn't always
> be intuitive.
2009/4/16 Antoine Pitrou :
> Paul Moore gmail.com> writes:
>>
>> Oh, certainly! But in the absence of "intuitive", I've found in the
>> past that "standardised" is often better than nothing (For
>> example, I use Oracle's add_months
2009/4/16 Ned Deily :
> In article
> ,
> Jess Austin wrote:
>> I'm new to python core development, and I've been advised to write to
>> python-dev concerning a feature/patch I've placed at
>> http://bugs.python.org/issue5434, with Rietveld at
>> http://codereview.appspot.com/25079.
>
> Without ha
2009/4/16 Robert Kern :
> On 2009-04-16 13:42, Paul Moore wrote:
>>
>> 2009/4/16 Ned Deily:
>>>
>>> In article
>>> ,
>>> Jess Austin wrote:
>>>>
>>>> I'm new to python core development, and I've been ad
2009/4/19 Steven Bethard :
> On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson
> wrote:
>> 2009/4/18 Nick Coghlan :
>>> I see a few options:
>>> 1. Abandon the "python" name for the 3.x series and commit to calling it
>>> "python3" now and forever (i.e. actually make the decision that Mitchell
>
2009/4/24 Simon Cross :
> On Fri, Apr 24, 2009 at 12:04 PM, Glenn Linderman wrote:
>> The goal of Unicode users everywhere is to use Unicode for everything, no?
>> After all, all "real" file should have Unicode based names, and the only
>> proper byte sequences that should exist are UTF-8 encodin
2009/4/24 Antoine Pitrou :
> Aahz pythoncraft.com> writes:
>>
>> The part that I haven't seen clearly addressed so far is what happens
>> when disks get mounted across OSes (e.g. NFS).
>
> Unless there's some kind of native NFS API for file access, it is hopelessly
> out
> of scope for Python. We
2009/4/24 Stephen J. Turnbull :
> Paul Moore writes:
>
> > The pros for Martin's proposal are a uniform cross-platform interface,
> > and a user-friendly API for the common case.
>
> A more accurate phrasing would be "... a user-friendly API for those
> who
2009/4/25 James Y Knight :
> On Apr 24, 2009, at 6:05 PM, Paul Moore wrote:
>>
>> - Windows systems where broken Unicode (lone surrogates or whatever)
>> isn't involved
>> - Unix systems where the user's stated filesystem encoding is correct
>>
>&
2009/4/25 "Martin v. Löwis" :
>> Following on from that, would this (under Martin's proposal) result in
>> programs receiving encoded strings, or just semantically-incorrect
>> ones?
>
> Not sure I understand the question - what is an "encoded string"?
Sorry. I was struggling to come up with termi
2009/4/27 Stephen J. Turnbull :
> I believe there are solutions that don't have that problem.
> Specifically, if the return values were bytes, or (better for 2.x,
> where bytes are strings as far as most programmers are concerned) as a
> new data type, to indicate that they're not text until the cl
2009/4/28 Glenn Linderman :
> So assume a non-decodable sequence in a name. That puts us into Martin's
> funny-decode scheme. His funny-decode scheme produces a bare string,
> indistinguishable from a bare string that would be produced by a str API
> that happens to contain that same sequence. D
2009/4/28 Antoine Pitrou :
> Paul Moore gmail.com> writes:
>>
>> I've yet to hear anyone claim that they would have an actual problem
>> with a specific piece of code they have written.
>
> Yep, that's the problem. Lots of theoretical problems noone has ev
2009/4/28 Mark Dickinson :
> Here's one more proposed change, this time for formatting
> of floats using format() and the empty presentation type.
> To avoid repeating myself, here's the text from the issue
> I just opened:
>
> http://bugs.python.org/issue5864
>
> """
> In all versions of Python fr
2009/4/30 "Martin v. Löwis" :
>> OK, so what's wrong with os.listdir() and similar functions returning a
>> unicode string for strings that correctly encode/decode, and with byte
>> strings for strings that are not valid unicode?
>
> See http://bugs.python.org/issue3187
> in particular msg71655
Ca
2009/4/30 Thomas Breuel :
> The analogous phenomenon will exist in Python with PEP 383. Let's say I
> have a C library with wide character interfaces and I pass it a unicode
> string from Python.(*)
[...]
> (*) There's actually a second, sutble issue. PEP 383 intends utf-8b only to
> be used for
2009/5/4 Bill Janssen :
> Hi, Christian.
>
> Christian Schubert wrote:
>
>> I've created an alternative profiler module which queries per-thread
>> CPU usage via netlink/taskstats, which limits the applicability to
>> Linux (which shouldn't be much of an issue, profiling is usually not
>> done by
2009/5/6 Antoine Pitrou :
> Martin v. Löwis v.loewis.de> writes:
>>
>> Despite there being also an error handler called "surrogates".
>
> People, perhaps we could end all the bikeshedding and call one of those
> handlers
> "surrogates-pass" and the other "surrogates-escape", which sounds quite
>
2009/5/9 Chris Withers :
> Martin v. Löwis wrote:
>>> I thought .pth files just had python in them?
>>
>> Not at all - they never did. They have paths in them.
>
> I've certainly seen them with python in, and that's what I hate about
> them...
AIUI, there was a small special case that lines starti
2009/5/19 Tarek Ziadé :
> On Sat, May 16, 2009 at 6:55 PM, P.J. Eby wrote:
>>
>> 1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a
>> valid character in filenames?
>
> I am changing this into a . for now.
I'm not following this thread at all, but can I put a strong vote
*
2009/5/29 David Abrahams :
> http://allmydata.org/trac/tahoe/ticket/704#comment:7 describes a
> situation where my macports-installed python25 had a pyOpenSSL egg
> installed in it by something other than macports (possibly by
> easy_install-2.5?) that was not compatible with the Python build. My
2009/6/2 Bugbee, Larry :
>> > > I don't hear a public outcry - only a single complainer.
>> >
>> > Clay repeatedly pointed out that other people have objected
>> > to ipaddr and been ignored. It's really, really disappointing
>> > to see you continue to ignore not only them, but the repeated
>> >
2009/6/3 Stephen J. Turnbull :
> Aahz writes:
>
> > On Tue, Jun 02, 2009, Guido van Rossum wrote:
> > >
> > > I hope we can learn from this.
> >
> > I'm not thrilled with adding more process just because we had a problem
> > here, and the only obvious solution I see is to require a PEP every
2009/6/2 R. David Murray :
> On Tue, 2 Jun 2009 at 21:02, Paul Moore wrote:
>> Simple example. If I want to scan all the IP addresses on my network
>> (my IP address is 192.168.1.101) I'd probably write:
>>
>> for i in range(253):
>> ip = '192.168
2009/6/3 :
> So, here are my recommendations:
>
> 1. Use the tracker for discussing tickets, so that it's easy to refer back
> to a previous point in the discussion, and so that people working on those
> tickets can easily find your commentary.
> 2. Use the mailing list for drawing attention to
2009/6/4 Nick Coghlan :
> Paul Moore wrote:
>> Mostly, I agree, but I definitely disagree, I'm afraid, on the use of
>> the tracker for discussions. To keep track of discussions on a ticket,
>> I have to personally keep a list of the tickets I'm interested in,
&g
2009/6/4 Dirkjan Ochtman :
> On Thu, Jun 4, 2009 at 3:02 PM, Jason R. Coombs wrote:
>> I wanted to share this with the community in case anyone else runs into this
>> issue. Also, if there's a recommended procedure for addressing this issue
>> (and others that might arise due to non-native line
2009/6/5 Nick Coghlan :
> Dirkjan Ochtman wrote:
>>> Essentially, pcbuild.sln is a binary file, and should be treated as
>>> such. Maybe it's an error in the Subversion setup that it's treated as
>>> text at all...
>>
>> Yes, it certainly seems that way.
>
> Except it isn't a binary file - it's a t
2009/6/6 Mark Hammond :
> Paul Moore wrote:
>>
>> 2009/6/5 Nick Coghlan :
>>>
>>> Dirkjan Ochtman wrote:
>>>>>
>>>>> Essentially, pcbuild.sln is a binary file, and should be treated as
>>>>> such. Maybe it's an er
2009/6/15 Terry Reedy :
> Raymond Hettinger wrote:
>
>> P.S. If you switch to PendingDeprecationWarning, the example
>> in the docs should probably be switched to show the one valid
>> use case (passing in a prepackaged nest of context managers).
>
> It could even suggest that it only be used for
I get the following:
>hg version
Mercurial Distributed SCM (version 1.2)
Copyright (C) 2005-2008 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>hg clone http://code.py
2009/6/19 Benjamin Peterson :
> Backwards compatibility seems to be an issue that arises a lot here. I
> think we all have an idea of it is, but we need some hard place to
> point to. So here's my attempt:
Nice :-)
A general point - it's probably worth clarifying that you're referring
to major re
2009/6/30 Guido van Rossum :
> And is there consensus outside of it? (Remember the ipaddr debacle.
> It's easy for people to miss an important PEP.)
My impression (as someone who does read the distutils SIG, but in all
honesty has very little practical interest in distutils internals):
- It's ver
2009/6/30 Tarek Ziadé :
> On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore wrote:
>> - The terminology and focus feels setuptools-inspired (my apologies if
>> that's not the case). Expect pushback from setuptools haters...
>
> setuptools implemented *needed* features, li
2009/6/30 Paul Moore :
> Thank you. I'll try to make the time to go through the PEP and comment
> more fully.
OK, I've now read the PEP through in full. My comments follow. I have
deliberately avoided mentioning points that others have already
raised, to keep things shorter.
Fir
2009/7/1 Tarek Ziadé :
> Right it's unclear, I'll work on this part.
>
> To resume :
>
> - Phase 1 : introduction of the egg-info file in distutils
>
> Philipp introduced the creation of a file named xxx.egg-info file in 2006
> (see http://bugs.python.org/issue1459476) alongside
> distutils-instal
2009/7/1 Paul Moore :
> 2009/6/30 Paul Moore :
>> Thank you. I'll try to make the time to go through the PEP and comment
>> more fully.
>
> OK, I've now read the PEP through in full. My comments follow.
One other thought. You haven't documented the Distribution
2009/7/1 Paul Moore :
> One other thought. You haven't documented the DistributionMetaData class. The
Just noticed that it's defined in distutils. But it's not documented there :-(
Maybe just add a bit to the PEP saying that the class exists in
distutils, give a brief summar
2009/7/1 Tarek Ziadé :
>> As I suggested before:
>>
>> python -m distutils.uninstall packagename
>
> yes sorry if it was unclear, I was not thinking about adding something
> based on setup.py,
> but just saying that I was going to add this feature in the PEP. and
> it will be of the form:
>
> p
2009/7/1 Tarek Ziadé :
>> That (at least as I read it) is a function, not a command.
>> If it is a command, give an example of its use from the command line
>> for us poor "don't want to research" people. If the following works:
>>
>> $ python setup.py uninstall some_package
>>
>> Then explicit
2009/7/1 R. David Murray :
> I haven't read the PEP in detail since it's outside my area of interest
> and knowledge(*), but my understanding of the goal is that the PEP is
> providing an _infrastructure_ for system-level package management tools.
> The uninstall function is part of that infrastruc
2009/7/2 Ben Finney :
> I think that calling distutils an “install program” is confusing. When
> I discuss distutils, I don't call it a program at all; it's a library
> (or perhaps “framework”) that provides part of the job of package
> installation.
I agree, but I consider the fact that distutils
2009/7/2 Tarek Ziadé :
> For absolute paths now that gets installed, what would be the
> difference between the pre-generated
> RECORD file and the RECORD file installed on the win32 target system, if any ?
When is an absolute path generated? If you can give me a small sample
of a distribution tha
2009/7/2 Tarek Ziadé :
> Try this setup.py file:
>
> """
> from distutils.core import setup
>
> setup(name='foo', version='1.0', data_files=[('/tmp', ['data'])])
> """
>
> with this MANIFEST.in file:
> ""
> include data
> """
>
> and add a 'data' file alongside
Ta. I'll give it a go tonight. But h
2009/7/2 Tarek Ziadé :
> On Thu, Jul 2, 2009 at 2:39 PM, Paul Moore wrote:
>> 2009/7/2 Tarek Ziadé :
>>> For absolute paths now that gets installed, what would be the
>>> difference between the pre-generated
>>> RECORD file and the RECORD file installed on
2009/7/3 Łukasz Langa :
>
> On 2009-06-22 at 14:23, Tarek Ziadé wrote:
>
>> Hello,
>>
>> We have polished out PEP 376 and its code prototype at Distutils-SIG.
>> It seems to fullfill now all the requirements,
>> so I am mailing it here again, for a new round of feedback, if needed.
>
>
> Hello.
> I
2009/7/3 Tarek Ziadé :
> On Fri, Jul 3, 2009 at 4:28 PM, Nick Coghlan wrote:
>> I will note (and I believe this is also the main point that Lukasz was
>> making) that having the distribution metadata outside the distribution
>> as currently proposed in PEP 376 is going to make any eventual PEP 302
2009/7/3 Nick Coghlan :
> I agree that even if the reference implementation of PEP 376 only
> handles normal directories and zipfiles, the PEP itself needs to explain
> how the developer of a custom PEP 302 importer or loader can hook into
> the mechanism in order to provide metadata that distutils
2009/7/3 P.J. Eby :
> Well, we could always resurrect PEP 365, since pkg_resources already has
> documented extensible support for arbitrary importers. That solves backward
> *and* forward compatibility. Then PEP 376's uninstall facilities could be
> implemented using pkg_resources' existing meta
This post basically follows on from the previous thread about PEP 376
(Changing the .egg-info structure) where it was pointed out that the
PEP doesn't cover PEP 302 import hooks (except in the explicit special
case of zip files). This is likely to be a fairly long posting, but
I'd like to try and c
2009/7/3 Tarek Ziadé :
> You can give me a bitbucket account so I can give you write access to the
> repo,
> There are tests as long as you install Nose.
How do I get the tests to work? Just running nosetests gives an error
(probably because pkgutil is being imported from the stdlib, rather
than
2009/7/3 Tarek Ziadé :
> 2009/7/3 Paul Moore :
>> Does this sound sensible? Tarek, would you be OK with me attempting to
>> modify your prototype to support this protocol? Are there any tests
>> for PEP 376, so that I can confirm I haven't completely broken
>> so
2009/7/4 Paul Moore :
> 2009/7/3 Tarek Ziadé :
>> You can give me a bitbucket account so I can give you write access to the
>> repo,
>> There are tests as long as you install Nose.
>
> How do I get the tests to work? Just running nosetests gives an error
> (pro
2009/7/4 Brett Cannon :
>> > Finder.uninstall(distribution_name, filter=callable, installer=name)
>> > Uninstall the given distribution. It's likely that many finders will
>> > be read-only. In that case, this function should return None.
>> > Otherwise, return a list of the "files" removed. (This
2009/7/5 Tarek Ziadé :
> Go for it please, and let me know if you set a bitbucket account, so
> you can push your commits in there directly
My bitbucket account is 'pmoore'.
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
2009/7/5 Tarek Ziadé :
> Agreed, the zip case was added afterwards, but in practice, the APIs are still
> dealing with the files are *filesystem files* located in a container (eg a
> directory
> or a zip file) located somewhere on the filesystem.
>
> "local" in that case is a flag that means "tran
The PEP says:
"""
get_egginfo_files(local=False) -> iterator of paths
Iterates over the RECORD entries and return paths for each line if the
path is pointing a file located in the .egg-info directory or one of
its subdirectory.
"""
Should this method really only return filenames noted in the REC
2009/7/5 P.J. Eby :
> At 05:26 PM 7/5/2009 +0100, Paul Moore wrote:
>>
>> def get_distribution(name):
>> for d in get_distributions():
>> if d.name == name:
>> return d
>> return None
>
> Btw, this is broken code anyway, beca
2009/7/5 Tarek Ziadé :
> 2009/7/5 Paul Moore :
>> The PEP says:
>>
>> """
>> get_egginfo_files(local=False) -> iterator of paths
>>
>> Iterates over the RECORD entries and return paths for each line if the
>> path is pointing a file l
2009/7/5 P.J. Eby :
> At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>
>> The loader would still work with "DIST_NAME.egg-info" directories for
>> compatibility with
>> existing format in the query APIs, but the Distutils install command
>> would rather create "DIST_NAME.metadata"
>
> Note that t
2009/7/6 P.J. Eby :
> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>
>> But if it's based on PEP 302 protocols and if the pkgutil code works
>> with the sys.meta_path hook,
>> setuptools could then provide its loader, based on its EggFormats and
>> act as a provider without being broken.
>
> You
2009/7/6 Tarek Ziadé :
> 2009/7/6 Ronald Oussoren :
>> I'm -1 on changing the name. For better or worse setuptools is the elephant
>> in the room w.r.t. package management and it would IMHO be better to stay
>> compatible (even if the stdlib only implements a subset of
>> setuptools/pkg_resources)
2009/7/6 Nick Coghlan :
> P.J. Eby wrote:
>> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>> But if it's based on PEP 302 protocols and if the pkgutil code works
>>> with the sys.meta_path hook,
>>> setuptools could then provide its loader, based on its EggFormats and
>>> act as a provider witho
2009/7/6 Tarek Ziadé :
> why can't we just go ahead and continue the work as we started with PEP 376,
> introducing your work on PEP 302-like behavior.
>
> Then if we get a consensus on this PEP and introduce it in 2.7/3.2,
> setuptools will have to follow this consensus.
Essentially, because when
2009/7/6 P.J. Eby :
> At 04:14 PM 7/6/2009 +0100, Paul Moore wrote:
>> This is getting confusing. Is Phillip saying that setuptools will cope
>> with the file changing to a directory without modification, but it
>> can't handle a change in the name?
>
> The exis
2009/7/6 P.J. Eby :
> At 07:18 PM 7/6/2009 +0200, Tarek Ziadé wrote:
>>
>> >> So is PEP 376 going to be able to cope with the stuff I have installed
>> >> at the moment? If not, what's the point???
>> >
>> > If I understand Tarek's proposal correctly, then no, it will not cope.
>>
>> Why that ? Can
As promised, here are some open questions on PEP 376.
- Will the public API names be changed from *egginfo* to *metadata*?
- What precisely are the use cases for absolute path names? Concrete
examples are needed. With the current spec, some things can go wrong
(e.g., see below), so we need real u
2009/7/6 Nick Coghlan :
> P.J. Eby wrote:
>> So, I'm +1 for no change (obviously), and +0 for "always .pydist in 3.x
>> and always .egg-info in 2.x", whether the latter part is achieved by
>> making distutils/pkgutil use a version-dependent extension, or by
>> refusing to backport distutils/pkgutil
2009/7/6 P.J. Eby :
> At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
>>
>> As promised, here are some open questions on PEP 376.
>>
>> - Will the public API names be changed from *egginfo* to *metadata*?
>
> +1 (FWIW, 'metadata' is what pkg_resources API
2009/7/6 Nick Coghlan :
> I'd add one more question to the list: is allowing backslash separated
> names in the RECORD file actually a good idea, or would it be better to
> always use forward slashes?
They do always use forward slashes.
> For the other questions, I don't have anything much to add
2009/7/7 Ben Finney :
> Paul Moore writes:
>
>> In fact, the above strongly suggests to me that PEP 376 must NOT
>> follow setuptools conventions - otherwise, it will end up clashing
>> with the files setuptools is putting on my system.
>
> I think the argument for
2009/7/7 Tarek Ziadé :
> Unless we define a "drive that contains the python installation" maybe, or
> the "Program Files" directory
>
> would that make sense from a win32 point of view ?
I can't imagine that it would be useful in practice.
> I know some people are writing to /etc to add their co
2009/7/7 M.-A. Lemburg :
> The PEP should take the chance to define not only the
> directory, but also the complete set of files in there and
> their format.
>
> A typical setuptools dir looks like this:
>
> dependency_links.txt
> namespace_packages.txt
> not-zip-safe
> PKG-INFO
> requires.txt
> SO
2009/7/7 M.-A. Lemburg :
> I think you have to differentiate between packages and applications.
Agreed. I believe that only packages should be considered here.
Applications are the focus of tools like py2exe on Windows, and (AIUI)
things like workingenv. These tools should (will) have their own
ap
2009/7/7 M.-A. Lemburg :
> Well I've added another one above, the pre-built approach :-)
Thanks! That's a lot of help. Are there any public examples, or is
your format only used internally?
Would you expect to use any of the new pkgutil APIs - for example, to
check if a distribution is installed,
2009/7/7 Ben Finney :
[... lots of interesting stuff deleted ...]
> I think it's not the developer's burden to decide *where* such files go;
> rather, they should be declaring only the *purpose* of these files in
> the distribution metadata, and it's up to the site-specific installer
> (possibly as
1001 - 1100 of 1862 matches
Mail list logo
