Re: [Python-Dev] PEP 376

[Michael Foord]

Kevin Teague wrote:


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.uninstall packagename". It can be
as minimalist as you like, but I'd like to see it present.


it's already there:

http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall-function


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 explicitly say so for us poor schlubs.



Right, I'll add that. Although it will be a reference implementation 
only.




Uninstall as a command feels a little weird. Since "python setup.py 
[some-command]" implies that the setup.py contains information about 
the distribution that the command is being applied to. So instead of:


$ python setup.py uninstall some_package


It could be:

   $ python -m distutils uninstall some_package

Asymmetrical with the install of course.

Michael



It could just be:

$ python setup.py uninstall

Except then you'd need to have a complete distribution kicking around 
with which to run the "python setup.py uninstall" command just to tell 
the uninstall command the distribution name you want to uninstall. But 
then with the other uninstall format you could uninstall any 
distribution from within any other distribution, which is convenient, 
but weird ... e.g.:


$ cd Spam-1.0/
$ python setup.py uninstall Foo

Although even the other version of the command could do weird stuff:

$ cd Spam-1.0/
$ python setup.py install
$ cd ../Spam-2.0/
$ python setup.py uninstall

Which would presumably remove the Spam 1.0 distribution when run from 
the 2.0 version of it! Or perhaps this command should only allow 
uninstall to be run from a distribution whose name and version match 
the one that it was installed from ...


I dunno what the right solution is. My two-cents is either to punt and 
only include an uninstall function as currently proposed, or for only 
supporting some form of the "python setup.py uninstall" style since I 
would guess that the most common use-case for uninstall is: user 
downloads a distribution, runs "python setup.py install", tries out 
the package, decides they don't like package, then runs "python 
setup.py uninstall" to restore their python back to it's original 
state. For doing anything more complex than that, people should be 
encouraged to use another one of the existing tools for managing their 
distributions, IMHO.


___
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/fuzzyman%40voidspace.org.uk 




--
http://www.ironpythoninaction.com/

___
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-archive.com

Re: [Python-Dev] PEP 376

[Tarek Ziadé]

On Wed, Jul 1, 2009 at 2:27 PM, Nick Coghlan wrote:
> However, having uninstall as a command supported by setup.py also makes
> a certain amount of sense.
>

Yes, that could be an alias that just calls the uninstall global
function using the distribution
name.
___
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-archive.com

Re: [Python-Dev] PEP 376

[Nick Coghlan]

Kevin Teague wrote:
> Uninstall as a command feels a little weird. Since "python setup.py
> [some-command]" implies that the setup.py contains information about the
> distribution that the command is being applied to. So instead of:
> 
> $ python setup.py uninstall some_package
> 
> It could just be:
> 
> $ python setup.py uninstall

I was actually thinking of something more along the lines of:

  python -m distutils uninstall 

(Older Pythons won't reliably let you execute a package like that, but
3.1+ and 2.7+ let you do it by including a __main__ module in the package)

However, having uninstall as a command supported by setup.py also makes
a certain amount of sense.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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-archive.com

Re: [Python-Dev] PEP 376

[Tarek Ziadé]

On Wed, Jul 1, 2009 at 10:35 AM, Paul Moore wrote:
> 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 explicitly say so for us poor schlubs.
>>>
>>
>> Right, I'll add that. Although it will be a reference implementation only.
>
> -1. Where does the setup.py file come from? If I have docutils
> installed, and want to remove it, must I download the source again so
> that I can get the setup.py, so I can run the uninstall? This is daft
> - particularly given that the point of PEP 376 is to ensure that all
> of the required information is available from the installed package!
>
> 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:

 python -m distutils.uninstall packagename

>
> Calling it a "reference implementation" should not imply that it's not
> built to be usable and complete. If it's there,m people should be able
> to use it.

It will be usable and complete, but very limited. As someone mentioned,
it will not take care of dependencies and prevent you from removing a
distribution that is mentioned in another distrubution in a
setuptools' install_requires
metadata.

That said, when PEP 345 evolves like we have planned to (adding
install_requires in the metadata)
Then we should be able to provide this kind of warning with no pain.
___
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-archive.com

Re: [Python-Dev] PEP 376

[Tarek Ziadé]

Right, the API part is almost empty,

http://docs.python.org/distutils/apiref.html

I'll complete it for the relevant part.

On Wed, Jul 1, 2009 at 2:37 PM, Paul Moore wrote:
> 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 summary, and say that as part of implimenting
> the PEP it will be formally documented. (Even though distutils is a
> mess of undocumented functionality, I don't think that you can base
> new work on undocumented internals - you should document them first,
> or things will never get any better :-()
>
> Paul.
>



-- 
Tarek Ziadé | http://ziade.org
___
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-archive.com

Re: [Python-Dev] PEP 376

[Tarek Ziadé]

On Wed, Jul 1, 2009 at 1:44 PM, Paul Moore wrote:
> "The problem is that many people use easy_install or pip to install
> their packages..."
>
> As already noted by others, it's not clear why this is a problem. But
> worse is the fact that the paragraph reads to me as saying that
> easy_install/pip/etc don't follow the *current* standard structure.
> Given this fact (which *is* a problem!) I fail to see why I should
> expect them to follow any *new* standard - so how does this PEP
> actually address the issue? Rather, it seems to say to me that the
> existing tools have a history of ignoring the standard approach, so
> this PEP is going to be useless :-(
>
> [I expect that isn't what you're trying to say, so you may just need
> to clarify your meaning. But I do think it's important to address the
> question of how this PEP is going to ensure that existing tools adapt.
> In particular, setuptools seems to have completely stagnated, so I see
> very little likelihood that setuptools is going to change to conform
> to the PEP - how does that affect things?]

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-installed package, that contains
the metadata of the distribution.

- Phase 2:  two new formats in the setuptools project

Then he created two new formats in the setuptools project:

1. an .egg-info directory containing a PKG-INFO file, which is similar
to the previous .egg-info file. This happened
   because other files were added in that directory.

2. an .egg directory, possibly zipped, that is a self-contained
version of the distribution, containing the metadata and all other
files.

Setuptools uses 2. by default. There's an option when you use
setuptools to force 1. (–single-version-externally-managed *or*
--root).

- Phase 3: adopting a unified standard.

It occurs that having a .egg-info directory (1.) is way better than a
single file because it's a place-holder for other files.
It is also adopted by the community when it comes to install
setuptools-based package.:

- This is what "pip" uses to install packages in a more flat manner.
- It's also the policy under debian
(http://wiki.debian.org/DebianPython/NewPolicy)
- and under Fedora
(http://fedoraproject.org/wiki/Packaging/Python/Eggs#Providing_Eggs_using_Setuptools)

The .egg directory (2.) is more controversial because it a
self-contained directory that doesn't install packages
so it makes two different ways to work with distributions for packagers.

So I have proposed in the PEP to adopt the standalone .egg-info
directory as the new distutils unified standard.

This means that all the third-party tools out there already conform to
that standard, and that packages installed
in other formats will not benefit from the new APIs. which means that
people that want to work with distributions installed as .egg
directories will have to use setuptools APIs.
Which makes sense.

>
> ".egg-info becomes a directory"
>
> Don't refer to the setuptools documentation (EggFormats)! It is
> obscure and user-hostile, as well as not actually being the same as
> the PEP's proposal. Rather, just document the structure of .egg-info.
> If you want, you can then add a cross-reference note, saying something
> like "The setuptools structure, as proposed in the EggFormats
> documentation for that package [ref], is a subset of this standard. In
> order to conform to this PEP, setuptools will have to be amended to
> only install .egg-info directories in the format defined by this PEP".

I'll work that way.

>
> "However, it will impact the setuptools and pip projects, but given
> the fact that..."
>
> Confusing. Will these tools need to change (I believe so) or not? If
> they will need to change, that hardly counts as "no deep consequences"
> - there's the whole backward compatibility issue for them to handle.

I'll add this in a backward compatibility section, as suggested
earlier by someone.

>
> "Adding a RECORD file"
>
> "The RECORD format"
>
> "Adding an INSTALLER file in the .egg-info directory"

These section will have more details about the way they interact with bdist_*

for the rest of the mail, I'll clarify the rest of the PEP using your feedback;

> "New APIs in pkgutil"
>
> You say "the best place to put these APIS seems to be pkgutil". You
> should be more definite - "these APIs will be added to the pkgutil
> module".

ok

> General rule - don't document (and commit yourself to) any internal
> details that the user can't access from the public API. It just makes
> backward compatibility harder to maintain.

The purpose is to provide this documentation to third-party projects that want
to implement a packaging system on the top of these classes.

Maybe this should be removed from the PEP and but into another
document targeted to developers ?

>
> "Adding an unins

Re: [Python-Dev] PEP 376

[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. I have
deliberately avoided mentioning points that others have already
raised, to keep things shorter.

First of all, after I got over the use of setuptools terminology, the
document is very good. It's clear what it's trying to achieve, and
covers most of the points I'd want it to. Occasionally the
presentation is confusing, see below, but I think everything was
there.

I do still feel that the setuptools focus will put some readers off.
The introductory remarks, in particular, assume a reasonable level of
familiarity from readers about setuptools, easy_install, pip and the
like. Not having that familiarity isn't a problem in fact, but the
assumption is there in the tone. (For example, personally, I hate the
unnecessarily cute term "egg", but it's established by now, so that's
a lost cause :-()

Onto the PEP.

"The problem is that many people use easy_install or pip to install
their packages..."

As already noted by others, it's not clear why this is a problem. But
worse is the fact that the paragraph reads to me as saying that
easy_install/pip/etc don't follow the *current* standard structure.
Given this fact (which *is* a problem!) I fail to see why I should
expect them to follow any *new* standard - so how does this PEP
actually address the issue? Rather, it seems to say to me that the
existing tools have a history of ignoring the standard approach, so
this PEP is going to be useless :-(

[I expect that isn't what you're trying to say, so you may just need
to clarify your meaning. But I do think it's important to address the
question of how this PEP is going to ensure that existing tools adapt.
In particular, setuptools seems to have completely stagnated, so I see
very little likelihood that setuptools is going to change to conform
to the PEP - how does that affect things?]

".egg-info becomes a directory"

Don't refer to the setuptools documentation (EggFormats)! It is
obscure and user-hostile, as well as not actually being the same as
the PEP's proposal. Rather, just document the structure of .egg-info.
If you want, you can then add a cross-reference note, saying something
like "The setuptools structure, as proposed in the EggFormats
documentation for that package [ref], is a subset of this standard. In
order to conform to this PEP, setuptools will have to be amended to
only install .egg-info directories in the format defined by this PEP".

"However, it will impact the setuptools and pip projects, but given
the fact that..."

Confusing. Will these tools need to change (I believe so) or not? If
they will need to change, that hardly counts as "no deep consequences"
- there's the whole backward compatibility issue for them to handle.

"Adding a RECORD file"

You say "at installation time" - please clarify. Do you only mean
setup.py install? What about bdist_wininst and bdist_msi? What about
third party bdist style tools? How will they ensure they get a RECORD
file?

"The RECORD format"

The line separator shouldn't be os-dependent. What value is used for a
pure-python (ie, platform independent) package? Unless the file is
generated when the install is done, in which case see the previous
point...

Absolute file paths - this implies that RECORD has to be generated by
the installer (which is the only place that knows absolute paths)
which means that every bdist_xxx installer has to write its own RECORD
file. Does the PEP offer no support for this? In any case, the
bdist_wininst and bdist_msi code (which is core distutils) will need
to be amended to manage RECORD files appropriately.

"Adding an INSTALLER file in the .egg-info directory"

Same question again - does the PEP offer supporting APIs to help
bdist_xxx installers do this? What about the core bdist_xxx commands?

"New APIs in pkgutil"

You say "the best place to put these APIS seems to be pkgutil". You
should be more definite - "these APIs will be added to the pkgutil
module".

The Distribution/ZippedDistribution and
DistributionDir/ZippedDistributionDir pairs seem to imply that users
need to explicitly instantiate these classes (and hence know whether a
distribution is zipped). This is cleared up later, but you should add
a note here - "Users will not need to create instances of these
classes manually, they are returned by the public functions in
pkgutil, such as get_distributions()".

"DistributionDirMap class"

This seems to be an internal implementation detail, and as such should
not be documented. It's never returned from any of the public APIs,
and the only created instance is a hidden internal global instance.
The whole part about purging the cache is also unnecessary - the user
has no interface to allow them to do this, so you don't need to
document that it's possible.

Actually, (Zipped)DistributionDir instances are never returned to the
user via the public API, either

Re: [Python-Dev] PEP 376

[Paul Moore]

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-installed package, that contains
> the metadata of the distribution.
>
> - Phase 2:  two new formats in the setuptools project
>
> Then he created two new formats in the setuptools project:
>
> 1. an .egg-info directory containing a PKG-INFO file, which is similar
> to the previous .egg-info file. This happened
>   because other files were added in that directory.
>
> 2. an .egg directory, possibly zipped, that is a self-contained
> version of the distribution, containing the metadata and all other
> files.
>
> Setuptools uses 2. by default. There's an option when you use
> setuptools to force 1. (–single-version-externally-managed *or*
> --root).
>
> - Phase 3: adopting a unified standard.
>
> It occurs that having a .egg-info directory (1.) is way better than a
> single file because it's a place-holder for other files.
> It is also adopted by the community when it comes to install
> setuptools-based package.:
>
> - This is what "pip" uses to install packages in a more flat manner.
> - It's also the policy under debian
> (http://wiki.debian.org/DebianPython/NewPolicy)
> - and under Fedora
> (http://fedoraproject.org/wiki/Packaging/Python/Eggs#Providing_Eggs_using_Setuptools)
>
> The .egg directory (2.) is more controversial because it a
> self-contained directory that doesn't install packages
> so it makes two different ways to work with distributions for packagers.
>
> So I have proposed in the PEP to adopt the standalone .egg-info
> directory as the new distutils unified standard.
>
> This means that all the third-party tools out there already conform to
> that standard, and that packages installed
> in other formats will not benefit from the new APIs. which means that
> people that want to work with distributions installed as .egg
> directories will have to use setuptools APIs.
> Which makes sense.

Ah, that makes a *lot* more sense. So, in a "compatibility" section,
you could point out that the proposed standard is compatible with
setuptools "single version externally managed" format, and that the
setuptools multi-version format (the egg file/directory) is a
non-standard format designed to allow multiple versions to be
installed at once - something out of scope for this PEP.

With that explanation, people like me who glaze over at the
complexities of setuptools scenarios should be able to see what's
going on.

Thanks for clarifying.

>> General rule - don't document (and commit yourself to) any internal
>> details that the user can't access from the public API. It just makes
>> backward compatibility harder to maintain.
>
> The purpose is to provide this documentation to third-party projects that want
> to implement a packaging system on the top of these classes.

Hmm, but you don't explain how they should do that. I certainly
wouldn't know how to. As the public API is pkgutil.get_distribution
(and the like) which isn't a class so cannot be subclassed, it's not
clear how a 3rd party could hook in a subclass of
(Zipped)Distribution. And as there's nothing in the public API that
consumes these classes, creating them by hand is of no use, either.

> Maybe this should be removed from the PEP and but into another
> document targeted to developers ?

No. If it's needed by developers, it should be defined in the PEP, not
elsewhere. But it should be defined in a way that developers can use -
not just for the sake of defining it. Unless there is a concrete use
case (which should be stated as an example in the PEP) then *not*
documenting the classes is of more help to developers, as they don't
have to follow a definition that isn't used.

Paul.
___
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-archive.com

Re: [Python-Dev] PEP 376

[Paul Moore]

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 DistributionMetaData class. The

And a minor nit:

"""
Distribution class

A new class called Distribution is created with a the path of the
.egg-info directory provided to the contructor. It reads the metadata
contained in PKG-INFO when it is instanciated.
"""

instantiated

Paul.
___
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-archive.com

Re: [Python-Dev] PEP 376

[R. David Murray]

On Tue, 30 Jun 2009 at 20:06, Scott David Daniels wrote:

Kevin Teague wrote:

 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.uninstall packagename". It can 
> > > >  be

> > > >  as minimalist as you like, but I'd like to see it present.
> > >  it's already there:
> > >  http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall-function
> >  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 explicitly say so for us poor schlubs.
>  Right, I'll add that. Although it will be a reference implementation 
>  only.

 Uninstall as a command feels a little weird
 I dunno what the right solution is. My two-cents is either to punt and
 only include an uninstall function as currently proposed, or for only
 supporting some form of the "python setup.py uninstall" style


But for us poor schlubs, we want you brilliant packagers to actually
come to a hard decision.  If you want approval either admit you have no
solution in the PEP (and detail the issues that prevent a decision),
provide a minimally acceptable command, or expect that nobody sees the
value of what you propose


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 infrastructure, but since
distutils isn't a package manager itself (it's an install program),
distutils as currently organized can't really handle uninstall except
as outlined in a section you may have clipped from the above context
(ie: when setup.py from the original package is available).

A possible implementation at the python/distutils level might be to
have a 'pyuninstall' command installed (like pydoc et al are installed)
which handles uninstallation.

The question is what do the people who do real package management
(linux distribution level package management and the equivalent) think?
I'm guessing they are happy with just having the function for their
package management tools to call when needed, since (I'm hoping) they
are part of the distutils sig

So, if my understanding of the overall goal is correct, it looks to me
like the PEP is missing a "motivation" section that talks about system
package managers.

--David

(*) I'll make time to read it anyway soon.___
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-archive.com

Re: [Python-Dev] PEP 376

[Tarek Ziadé]

On Wed, Jul 1, 2009 at 10:20 AM, Michael Foord wrote:
>>
>> Uninstall as a command feels a little weird. Since "python setup.py
>> [some-command]" implies that the setup.py contains information about the
>> distribution that the command is being applied to. So instead of:
>>
>> $ python setup.py uninstall some_package
>
> It could be:
>
>   $ python -m distutils uninstall some_package
>
> Asymmetrical with the install of course.
>

Yes exactly, I was going to add:

$ python -m distutils.uninstall some_package

The whole point of the RECORD file is to be able to uninstall without
depending on the original
archive used to install
___
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-archive.com

[Python-Dev] [Fwd: [issue6397] Implementing Solaris "poll" in the "select" module]

[Jesus Cea]

-- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--- Begin Message ---

New submission from Jesús Cea Avión :

In Python 2.6 we added support for Linux "epoll" and *BSD "kqueue" in
the select module. I think we should add support for Solaris "poll"
interface too.

What do you think?.

I volunteer to do the work, if you agree this is a feature we want to
have. I think so.

--
assignee: jcea
components: Library (Lib)
messages: 89989
nosy: jcea
severity: normal
stage: needs patch
status: open
title: Implementing Solaris "poll" in the "select" module
type: feature request
versions: Python 2.7, Python 3.2

___
Python tracker 

___

--- End Message ---
___
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-archive.com

[Python-Dev] I am back

[Brett Cannon]

Assuming Mailman flipped the right bits to start delivering mail to me
again, my Python sabbatical is now over.
Anything happen while I was gone that I should be aware of that is not
covered in a PEP?

-Brett
___
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-archive.com

Re: [Python-Dev] PEP 376

[Paul Moore]

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 summary, and say that as part of implimenting
the PEP it will be formally documented. (Even though distutils is a
mess of undocumented functionality, I don't think that you can base
new work on undocumented internals - you should document them first,
or things will never get any better :-()

Paul.
___
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-archive.com

Re: [Python-Dev] PEP 376

[Nick Coghlan]

Tarek Ziadé wrote:
>> - What is a "local absolute path"? Absolute path I understand, relative
>> path I understand, but "local absolute" is a novel term to me.
> 
> local means that the "/" separator that is used in the RECORD file for 
> example,
> no matter what platform you are on, is translated using the local separator
> (/ or \)
> 
> I'll make it clearer,

OK, I understand now. That makes Paul's questions about how to correctly
generate the RECORD file for bdist_xxx installations all the more
relevant though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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-archive.com

[Python-Dev] Bytes, Strings, Encoding

[Eric Pruitt]

Hello,

I am working on the subprocess.Popen module for Python 2.7 and am now moving
my changes over to Python 3.1 however I am having trouble with the whole
byte situation and I can't quite seem to understand how to go back and forth
between bytes and strings. I am also looking for the Python 3k equivalent
for the Python 2.X built-in buffer class.

One version of the file with my modifications can be found here  <
http://code.google.com/p/subprocdev/source/browse/subprocess.py?spec=svn5b570f8cbfcaae859091eb01b21b183aa5221af9&r=5b570f8cbfcaae859091eb01b21b183aa5221af9>.
Lines 1 - 15 are me attempting to get around certain changes between
Python 3.0 and Python 2.7. Further down on line 916, we have the function
"send" and "recv" in which I am having the most trouble with bytes and
strings.

Any help is appreciated. Feel free to comment on my blog
http://subdev.blogspot.com/ or reply to the last.

Thanks in advance,
Eric
___
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-archive.com

Re: [Python-Dev] [Fwd: [issue6397] Implementing Solaris "poll" in the "select" module]

[Guido van Rossum]

The select module already supports the poll() system call. Or is there
a special variant that only Solaris has?

2009/7/1 Jesus Cea :
>
> --
> Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
> j...@jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
> jabber / xmpp:j...@jabber.org         _/_/    _/_/          _/_/_/_/_/
> .                              _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
>
>
> -- Forwarded message --
> From: "Jesús Cea Avión" 
> To: j...@jcea.es
> Date: Wed, 01 Jul 2009 16:49:15 +
> Subject: [issue6397] Implementing Solaris "poll" in the "select" module
>
> New submission from Jesús Cea Avión :
>
> In Python 2.6 we added support for Linux "epoll" and *BSD "kqueue" in
> the select module. I think we should add support for Solaris "poll"
> interface too.
>
> What do you think?.
>
> I volunteer to do the work, if you agree this is a feature we want to
> have. I think so.
>
> --
> assignee: jcea
> components: Library (Lib)
> messages: 89989
> nosy: jcea
> severity: normal
> stage: needs patch
> status: open
> title: Implementing Solaris "poll" in the "select" module
> type: feature request
> versions: Python 2.7, Python 3.2
>
> ___
> Python tracker 
> 
> ___
>
>
> ___
> 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/guido%40python.org
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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-archive.com

Re: [Python-Dev] Bytes, Strings, Encoding

[Benjamin Peterson]

2009/7/1 Eric Pruitt :
> Hello,
>
> I am working on the subprocess.Popen module for Python 2.7 and am now moving
> my changes over to Python 3.1 however I am having trouble with the whole
> byte situation and I can't quite seem to understand how to go back and forth
> between bytes and strings. I am also looking for the Python 3k equivalent
> for the Python 2.X built-in buffer class.

Look at the "memoryview" type as a replacement for buffer.
io.Buffered* is not the same.

>
> One version of the file with my modifications can be found here  <
> http://code.google.com/p/subprocdev/source/browse/subprocess.py?spec=svn5b570f8cbfcaae859091eb01b21b183aa5221af9&r=5b570f8cbfcaae859091eb01b21b183aa5221af9
>>. Lines 1 - 15 are me attempting to get around certain changes between
> Python 3.0 and Python 2.7. Further down on line 916, we have the function
> "send" and "recv" in which I am having the most trouble with bytes and
> strings.

You translate between bytes and strings through encoding and decoding.
Have you read https://secure.wikimedia.org/wikipedia/en/wiki/Unicode?

>
> Any help is appreciated. Feel free to comment on my blog
> http://subdev.blogspot.com/ or reply to the last.

Have you talked with your mentor about these things?


-- 
Regards,
Benjamin
___
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-archive.com

Re: [Python-Dev] PEP 376

[Martin v. Löwis]

> I dunno what the right solution is.

I feel that it is straight forward. Either provide a
/usr/bin/python-uninstall utility, or arrange to make
python -mdistutils.uninstall work, so one would do

python -mdistutils.uninstall some_package

Regards,
Martin
___
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-archive.com

Re: [Python-Dev] I am back

[Aahz]

On Wed, Jul 01, 2009, Brett Cannon wrote:
>
> Anything happen while I was gone that I should be aware of that is not
> covered in a PEP?

Yes.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha
___
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-archive.com

Re: [Python-Dev] PEP 376

[P.J. Eby]

At 04:29 PM 7/1/2009 +0200, Tarek Ziadé wrote:

- 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-installed package, that contains
the metadata of the distribution.

- Phase 2:  two new formats in the setuptools project

Then he created two new formats in the setuptools project:


This is backwards.

The .egg-info file was added to distutils and setuptools *after* 
support for the other formats.  In other words, it was a third format 
added to allow other software (such as setuptools and friends) to 
detect the presence of packages installed via the distutils, and 
thereby prevent other tools from installing duplicates.


(.egg-info directories and .egg files/directories already existed.)



This means that all the third-party tools out there already conform to
that standard, and that packages installed
in other formats will not benefit from the new APIs. which means that
people that want to work with distributions installed as .egg
directories will have to use setuptools APIs.
Which makes sense.


Yes and no.  Not providing uninstall support is reasonable, but the 
PEP also has features to query packages in general.


(There's also no technical reason why comparable manifest and 
uninstall support can't be provided for .egg files and directoriees, 
since they already have an implicit manifest: their 
contents.  However, since I'm not currently possessed of the time to 
provide a patch myself, I'm not going to lobby for this as a feature.)




> If you want, you can then add a cross-reference note, saying something
> like "The setuptools structure, as proposed in the EggFormats
> documentation for that package [ref], is a subset of this standard. In
> order to conform to this PEP, setuptools will have to be amended to
> only install .egg-info directories in the format defined by this PEP".

I'll work that way.


(Technically, it's an extension of a subset of EggFormats, since it 
adds RECORD and INSTALLER.)




>
> "However, it will impact the setuptools and pip projects, but given
> the fact that..."
>
> Confusing. Will these tools need to change (I believe so) or not? If
> they will need to change, that hardly counts as "no deep consequences"
> - there's the whole backward compatibility issue for them to handle.

I'll add this in a backward compatibility section, as suggested
earlier by someone.


They don't need to change, unless they're going to support being 
uninstalled by the tool (in which case they'll need to add RECORD and 
INSTALLER).


___
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-archive.com

Re: [Python-Dev] PEP 376

[Paul Moore]

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:
>
>  python -m distutils.uninstall packagename
>
>>
>> Calling it a "reference implementation" should not imply that it's not
>> built to be usable and complete. If it's there,m people should be able
>> to use it.
>
> It will be usable and complete, but very limited. As someone mentioned,
> it will not take care of dependencies and prevent you from removing a
> distribution that is mentioned in another distrubution in a
> setuptools' install_requires
> metadata.

Thank you. That is precisely the right level for the PEP, IMHO.

> That said, when PEP 345 evolves like we have planned to (adding
> install_requires in the metadata)
> Then we should be able to provide this kind of warning with no pain.

That's good, but not something that bothers me too much. (I'm still of
the view that dependencies should be handled by documenting them
properly - metadata isn't sufficient on its own).

Paul.
___
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-archive.com

Re: [Python-Dev] [Fwd: [issue6397] Implementing Solaris "poll" in the "select" module]

[Alexandre Vassalotti]

On Wed, Jul 1, 2009 at 10:05 PM, Guido van Rossum wrote:
> The select module already supports the poll() system call. Or is there
> a special variant that only Solaris has?
>

I think Jesus refers to /dev/poll—i.e., the interface for
edge-triggered polling on Solaris. This is the Solaris equivalent of
FreeBSD's kqueue and Linux's epoll.

-- Alexandre
___
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-archive.com

Re: [Python-Dev] PEP 376

[Stephen J. Turnbull]

Tarek Ziadé writes:
 > On Wed, Jul 1, 2009 at 1:44 PM, Paul Moore wrote:

 > > General rule - don't document (and commit yourself to) any
 > > internal details that the user can't access from the public
 > > API. It just makes backward compatibility harder to maintain.
 > 
 > The purpose is to provide this documentation to third-party
 > projects that want to implement a packaging system on the top of
 > these classes.

That's a judgment you must make.  However, Paul's opinion seems to be
that it is internal, and not needed by third-parties who are working
"on the top" of these classes.  If upon consideration you agree, you
should take those "details" out of the PEP proper.  If you disagree,
you should promote them to the "official"/public API.

The point of a PEP is not to construct a duck; it is to explain what
"quack" means.

 > Maybe this should be removed from the PEP and but into another
 > document targeted to developers ?

Yes.  In the reference implementation (aka prototype), which should
have its own documentation as usual.  The reference implementation for
the PEP shows *how* these things can be done.  It must do that, or the
PEP has no force.  However, the reference implementation need not be
"industrial strength"; the actual implementation that eventually goes
into the stdlib may very well be an optimized and enhanced version
with many data structures and algorithms that differ from the
reference implementation.

Another general principle: even in the draft PEP, say "is", not "will
be".  If you're wrong, and that won't work; if it's insufficiently
precise; if you find a more elegant way to express the solution; if
you simply haven't thought carefully about something yet; if, for
whatever reason, you may need to change the PEP, then you change it in
the next draft.  That's why we have a review cycle, so you can change
it.  If you yourself have a question, or the draft is incomplete at
some point, then you can explain in a note (either a footnote or
parentheses).  You can even mark a whole section as "speculative" (eg,
"nothing in this section has been implemented yet, so everything is
subject to change").  But a rule should be stated as a rule, and
precisely, so that reviewers can criticize it accurately.

If you're uncomfortable saying "is", then maybe that part of the draft
isn't ready for public review yet.  On the other hand, you can use the
reviewers' knowledge here: write "A is B", then as a note "(In some
cases A is actually C, and this should be treated specially.  But
how?)"

___
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-archive.com

Re: [Python-Dev] PEP 376

[Paul Moore]

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 explicitly say so for us poor schlubs.
>>
>
> Right, I'll add that. Although it will be a reference implementation only.

-1. Where does the setup.py file come from? If I have docutils
installed, and want to remove it, must I download the source again so
that I can get the setup.py, so I can run the uninstall? This is daft
- particularly given that the point of PEP 376 is to ensure that all
of the required information is available from the installed package!

As I suggested before:

python -m distutils.uninstall packagename

Calling it a "reference implementation" should not imply that it's not
built to be usable and complete. If it's there,m people should be able
to use it.

Paul.
___
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-archive.com