[Python-Dev] Flow of control - a new way - Idea

[vin vin]

HI all

I am not the too technical guy, but thinking about the new way of
controlling the flow instead of throwing an error.

as of now if we need to break a control and go back, exceptions helps,
but it is not a actual way.

it would be great if we have a control over the frames execution, I mean

A  calls B which calls C which calls D

at that point if we think to move directly to B (what error handler do
if that B has the handler defined of the error), changing the frames
instruction pointer to back to the B's position (in python code without
raising an exception) is a really useful for this web applications.

-
How we can achieve this? a simple way?

Actually python interpreter currently doing this.
How?

method *A*

   method *B* <== has exception handler try: except:

  method *C*

 method *D*  <= got exception here..

now exception handler checks that which caller methods has the exception
handler provided for this exception. in our case method B has this. so, the
instruction pointer has moved back to that method B with the exception.
---

We can have this same functionality* BUT WITHOUT THE USE OF EXCEPTION*.

where it can help?

so many places, & it gives the full power of execution control to the user.

A simple usage of this is :

Currently most of the WSGI frameworks breaking the flow if needed to go on
another route, it simple raising the exception, But if any of the called
modules handled those exceptions it fails the flow. and we can't guide the
extension modules to don't use full try except as it is the pythons power.

What you say?

Please excuse me if we have this control already, (can u explain?)

I hope, currently no languages gives such full control over coders.

-- 
Thanks
Vinoth
___
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]

Martin v. Löwis wrote:
>> If no one objects, I'd like to push PEP 376 in the "accepted" status
>> and go ahead with its implementation,
>> with continuous feedback at Distutils-SIG as we did to build it.
> 
> I think this isn't quite the process. In the past, every PEP required
> BDFL pronouncement, which you should now seek.

Agreed. While Guido is highly likely to just accept the distutils-sig
consensus on something like this, that doesn't eliminate the need for
him to actually *say* that he is approving the PEP on that basis.

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] Flow of control - a new way - Idea

[Nick Coghlan]

vin vin wrote:
> 
> HI all
> 
> I am not the too technical guy, but thinking about the new way of
> controlling the flow instead of throwing an error.

This message is too speculative/tentative for python-dev (which is about
concrete development of the next version of Python) or even python-ideas
(which is the list for speculative proposals that may possibly be
considered some day).

I suggest taking this question to the general python list
(python-l...@python.org, also available as the newsgroup comp.lang.python).

Regards,
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 Tue, Jun 30, 2009 at 2:32 PM, Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> If no one objects, I'd like to push PEP 376 in the "accepted" status
>>> and go ahead with its implementation,
>>> with continuous feedback at Distutils-SIG as we did to build it.
>>
>> I think this isn't quite the process. In the past, every PEP required
>> BDFL pronouncement, which you should now seek.
>
> Agreed. While Guido is highly likely to just accept the distutils-sig
> consensus on something like this, that doesn't eliminate the need for
> him to actually *say* that he is approving the PEP on that basis.

Sure, I didn't want to bypass the process, I was not really sure about
the right move on this PEP
since it was based on the summit decisions,

I'll wait for Guido decision, thanks.

Cheers
Tarek

-- 
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] Flow of control - a new way - Idea

[Daniel Stutzbach]

On Tue, Jun 30, 2009 at 1:07 AM, vin vin<4vin...@gmail.com> wrote:
> at that point if we think to move directly to B (what error handler do
> if that B has the handler defined of the error), changing the frames
> instruction pointer to back to the B's position (in python code without
> raising an exception) is a really useful for this web applications.

If I understand you correctly, the language feature you are looking for is
called a "continuation", which was originally developed in the LISP/Scheme
world (as "call/cc").  I'm not familiar with the details, but I believe you
can get them in Stackless Python.

Hope that helps,

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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

[Guido van Rossum]

On Tue, Jun 30, 2009 at 5:32 AM, Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> If no one objects, I'd like to push PEP 376 in the "accepted" status
>>> and go ahead with its implementation,
>>> with continuous feedback at Distutils-SIG as we did to build it.
>>
>> I think this isn't quite the process. In the past, every PEP required
>> BDFL pronouncement, which you should now seek.
>
> Agreed. While Guido is highly likely to just accept the distutils-sig
> consensus on something like this, that doesn't eliminate the need for
> him to actually *say* that he is approving the PEP on that basis.

Sure. :-)

So what *is* the distutils-sig consensus?

And is there consensus outside of it? (Remember the ipaddr debacle.
It's easy for people to miss an important PEP.)

-- 
--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] PEP 376

[P.J. Eby]

At 07:57 PM 6/29/2009 +0200, Tarek Ziadé wrote:

Hello,

If no one objects, I'd like to push PEP 376 in the "accepted" status
and go ahead with its implementation,
with continuous feedback at Distutils-SIG as we did to build it.


I do have a question about the current draft...  Do zipped 
distributions use EGG-INFO or a project-version.egg-info?  This isn't 
spelled out in the PEP, although I get the general idea that the 
EGG-INFO format isn't supported, and thus the PEP and API do not 
support existing .egg files.  This should probably be made clear, if 
that's the intention.


___
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/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 very focused on distutils internals. If it has an impact on end
users (as opposed to packagers), it's very hard to discern. The only
hint of such a thing is the mention of an uninstall function. But it's
only an API. So still no end user impact [1] :-(
- The terminology and focus feels setuptools-inspired (my apologies if
that's not the case). Expect pushback from setuptools haters...
- It's quite dense for the casual reader not familiar with the
terminology. I've never managed to read the whole thing through,
personally.

I'd suggest two things:
- Add a section to the PEP describing the purely end user impact of the changes
- Post that to python-list, with a note pointing to the PEP for people
who care about distutils details

If that gets no feedback, you've done as much as you can.

Paul.

[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.
___
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]

> - Post that to python-list, with a note pointing to the PEP for people
> who care about distutils details

If that hasn't been done before (I have not followed), it should be done
right away. PEP 1 makes it a mandatory requirement for acceptance.

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] PEP 376

[Tarek Ziadé]

2009/6/30 Guido van Rossum :
> On Tue, Jun 30, 2009 at 5:32 AM, Nick Coghlan wrote:
>> Martin v. Löwis wrote:
 If no one objects, I'd like to push PEP 376 in the "accepted" status
 and go ahead with its implementation,
 with continuous feedback at Distutils-SIG as we did to build it.
>>>
>>> I think this isn't quite the process. In the past, every PEP required
>>> BDFL pronouncement, which you should now seek.
>>
>> Agreed. While Guido is highly likely to just accept the distutils-sig
>> consensus on something like this, that doesn't eliminate the need for
>> him to actually *say* that he is approving the PEP on that basis.
>
> Sure. :-)
>
> So what *is* the distutils-sig consensus?

The consensus is to have one and only one way to install distributions
in Python,
and a way to retrieve information on installed distributions, and their files.


>
> And is there consensus outside of it? (Remember the ipaddr debacle.
> It's easy for people to miss an important PEP.)

I am not sure who you are thinking about,

I am blogging a lot on the topic and I am trying to get key players
involved in this, like os packagers etc.

We've built this PEP in respect with existing tools like setuptools,
etc, and I am sending mails at python-dev
to make sure evereyone involved in python development has a chance to
provide some feedback,


>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>



-- 
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] Flow of control - a new way - Idea

[Terry Reedy]

vin vin wrote:

Look up 'trampoline', but ask any further questions on python-list.

___
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 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, like a way for developers to browse
installed packages.

We said during the summit at Pycon that we wanted this feature in
Distutils, (Guido said so)

So I worked in PEP 376 to introduce them.

Now if the fact that we want to introduce the good ideas of setuptools
into distutils,
(problems Phillip resolved) will make people push it back *even* they
are good idead, needed features,
 is something we need to fight against.

> - It's quite dense for the casual reader not familiar with the
> terminology. I've never managed to read the whole thing through,
> personally.

I'll try to add a definitions section,

>
> I'd suggest two things:
> - Add a section to the PEP describing the purely end user impact of the 
> changes
> - Post that to python-list, with a note pointing to the PEP for people
> who care about distutils details
>

Ok.

> If that gets no feedback, you've done as much as you can.

I hope it'll make it one day. If not, I don't understand the goal of
the "Python Language Summit'

>
> Paul.
>
> [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


Regards
Tarek

-- 
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é]

2009/6/30 P.J. Eby :
> At 07:57 PM 6/29/2009 +0200, Tarek Ziadé wrote:
>>
>> Hello,
>>
>> If no one objects, I'd like to push PEP 376 in the "accepted" status
>> and go ahead with its implementation,
>> with continuous feedback at Distutils-SIG as we did to build it.
>
> I do have a question about the current draft...  Do zipped distributions use
> EGG-INFO or a project-version.egg-info?  This isn't spelled out in the PEP,
> although I get the general idea that the EGG-INFO format isn't supported,
> and thus the PEP and API do not support existing .egg files.  This should
> probably be made clear, if that's the intention.

The intention is to have only one standard for the egg-info, I have
explained it in this section:

http://www.python.org/dev/peps/pep-0376/#egg-info-becomes-a-directory

previous formats will not be supported but that won't break anything of course
since the new APIs will work only over the distribution installed with
the new version
of distutils.



>
>



-- 
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

[Martin v. Löwis]

Tarek Ziadé wrote:
> 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, like a way for developers to browse
> installed packages.

That doesn't imply that setuptools itself is needed. I can browse
installed packages with dpkg -l, or "add-and-remove programs".

> Now if the fact that we want to introduce the good ideas of setuptools
> into distutils,
> (problems Phillip resolved) will make people push it back *even* they
> are good idead, needed features,
>  is something we need to fight against.

Assuming "we" have consensus before we start fighting against others.

FWIW, I abstain from commenting on PEP 376. I don't need it, but it
doesn't seem to hurt having it, especially since "egg-info" already
managed to sneak in.

> I hope it'll make it one day. If not, I don't understand the goal of
> the "Python Language Summit'

Just be patient. Both Python 2.7 and 3.2 are still many months ahead,
so there is no urgency (AFAICT).

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] PEP 376

[Scott David Daniels]

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.

--Scott David Daniels
scott.dani...@acm.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

[Paul Moore]

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, like a way for developers to browse
> installed packages.

No problem with any of that. Please understand that on the whole, I'm
in favour of the setuptools features. (While I dislike intensely some
of the setuptools "ecosystem", such as easy_install. In fact, one of
my goals in wanting this PEP accepted is to ensure that I can get the
"good bits" of setuptools, without having to buy into the
easy_install, dependency management, automated download infrastructure
that currently goes with it).

> We said during the summit at Pycon that we wanted this feature in
> Distutils, (Guido said so)

"We" in this context denotes the people at the summit. Please remember
that people who weren't there still have an opinion - and it may well
differ. I'm not saying that it *does* differ, just that the view of
the summit should not be viewed as conclusive (unless the way Python
is developed is very different from how I understand it).

> So I worked in PEP 376 to introduce them.

And as with any PEP, that's a difficult and thankless task (I got a
taste myself with PEP 302, and that was far easier), so just for the
record, you have my thanks for doing this.

> Now if the fact that we want to introduce the good ideas of setuptools
> into distutils,
> (problems Phillip resolved) will make people push it back *even* they
> are good idead, needed features,
>  is something we need to fight against.

But there *are* issues with setuptools. Some users have mentioned them
on a number of occasions. I've raised a few myself. By all means
introduce the good ideas into the core - but make sure people agree
that the ideas *are* good.

And remember - all I said was that people may react against the
setuptools-style terminology. Not that they dislike the *idea*, just
that they might dislike the way it's presented. After all, one common
complaint with setuptools (and one that I agree with) is that its
documentation is obscure to the point of being hostile.

>> - It's quite dense for the casual reader not familiar with the
>> terminology. I've never managed to read the whole thing through,
>> personally.
>
> I'll try to add a definitions section,

Thank you. I'll try to make the time to go through the PEP and comment
more fully.

>> [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

No, that defines an API, which as stated in the PEP, "allows a
third-party application to use the uninstall function and make sure
it's the only program that can remove a distribution it has previously
installed". It does NOT define a standard uninstall command, to
complement the standard install command.

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:
> 2009/6/30 P.J. Eby :
>> At 07:57 PM 6/29/2009 +0200, Tarek Ziadé wrote:
>>> Hello,
>>> 
>>> If no one objects, I'd like to push PEP 376 in the "accepted"
>>> status and go ahead with its implementation, with continuous
>>> feedback at Distutils-SIG as we did to build it.
>> I do have a question about the current draft...  Do zipped
>> distributions use EGG-INFO or a project-version.egg-info?  This
>> isn't spelled out in the PEP, although I get the general idea that
>> the EGG-INFO format isn't supported, and thus the PEP and API do
>> not support existing .egg files.  This should probably be made
>> clear, if that's the intention.
> 
> The intention is to have only one standard for the egg-info, I have 
> explained it in this section:
> 
> http://www.python.org/dev/peps/pep-0376/#egg-info-becomes-a-directory
> 
> 
> previous formats will not be supported but that won't break anything
> of course since the new APIs will work only over the distribution
> installed with the new version of distutils.

To address PJE's question in the PEP, it may be worth expanding on this
in the backwards compatibility section explaining how the new distutils
metadata system avoids getting confused by the old pre-standardisation
installation formats (e.g. it may be that the directory names and/or
filenames all deliberately differ from current approaches precisely so
they can coexist without interfering with each other)

Also, I find the following paragraph (near the start of the section
linked above) confusing:

[PEP 376]
> Notice that this change is based on the standard proposed by
> EggFormats, although this standard proposes two ways to install
> files:
> 
> * A self-contained directory that can be zipped or left unzipped and
> contains the distribution files and the .egg-info directory.
> * A distinct .egg-info directory located in the site-packages directory.

This is unclear as to what "this standard" is referring to (since the
PEP itself is proposing a standard, but the sentence is also referring
to the existing EggFormats de facto standard). If the PEP only supports
the latter of the two options (which appears to be the case) it should
say so explicitly.

Another minor nit from the same section:

[PEP 376]
> Any '-' characters are currently replaced with '_'.

This should say something like "Any '-' characters other than the one in
'egg-info' and the one separating the name from the version number are
included in the replacement of non-alphanumeric characters with '_'"

Other questions/comments:

- What is a "local absolute path"? Absolute path I understand, relative
path I understand, but "local absolute" is a novel term to me.

- In DistributionDirMap constructor description: "is not not" -> "is not
None"

 - as Paul Moore suggested, exposing a distutils based uninstall command
at the command line may make sense (and if it doesn't, the PEP should
say why not)

Otherwise, from a non-expert point of view I actually find the PEP
pretty readable and clear, and it all looks like a pretty sensible
design to me.

Regards,
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

[Steven D'Aprano]

On Wed, 1 Jul 2009 05:19:07 am Tarek Ziadé wrote:
> 2009/6/30 Guido van Rossum :
...
> > So what *is* the distutils-sig consensus?
>
> The consensus is to have one and only one way to install
> distributions in Python,

"One and only one way"? Shouldn't that be "one obvious way"?

There is a big difference -- the first implies that Python should 
actively prohibit (somehow!) or at least inhibit any other install 
mechanisms, while the second implies that there should be a preferred, 
obvious, but not compulsory, mechanism.

If you say "one and only one", and I take you at your word, then I can 
only assume that you want to actively prevent me from manually 
dropping .py files into my PYTHONPATH and having them work. I would 
guess that's probably not what you mean, but that's what it sounds like 
you're proposing. I don't like guessing -- would you please clarify 
what you mean?


Some questions and comments regarding the PEP:

Rationale:
http://www.python.org/dev/peps/pep-0376/#id13

"There are too many ways to do it."

Why is having multiple ways of adding distributions a problem to be 
solved? On my Linux system, I can add packages with rpm/yum, or I can 
compile them from source and manage them myself. I possibly even could 
(but never have!) install apt-get and use it to manage packages.

Another rationale which should be added:

There is no standard way of uninstalling distributions.


How distributions are installed:
http://www.python.org/dev/peps/pep-0376/#id14

"The problem is that many people use easy_install (from the setuptools 
project [4]) or pip [5] to install their packages, and these 
third-party tools do not install packages in the same way that 
Distutils does"

Why is that a problem to be solved?


Uninstall information:
http://www.python.org/dev/peps/pep-0376/#id15

"Under some circumstances, you might not be able to know for sure that 
you have removed everything, or that you didn't break another 
distribution by removing a file that is shared among several 
distributions."

I don't see how this proposal will help in the second case. If you 
install distribution Spam, containing file spam.py, and then install 
distribution Ham, which requires spam.py, what is to prevent you from 
removing Spam and breaking Ham?

If you don't propose a solution for the dependency problem, you should 
say so.


The RECORD format:
http://www.python.org/dev/peps/pep-0376/#id19

"Each record is composed of three elements.
...
the MD5 hash of the file, encoded in hex. Notice that pyc and pyo 
generated files will not have a hash because they are automatically 
produced from py files."

What if your distribution is not a source distribution and only provides 
pyc and pyo files?



-- 
Steven D'Aprano
___
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 12:47 AM, Steven D'Aprano wrote:
> On Wed, 1 Jul 2009 05:19:07 am Tarek Ziadé wrote:
>> 2009/6/30 Guido van Rossum :
> ...
>> > So what *is* the distutils-sig consensus?
>>
>> The consensus is to have one and only one way to install
>> distributions in Python,
>
> "One and only one way"? Shouldn't that be "one obvious way"?
>
> There is a big difference -- the first implies that Python should
> actively prohibit (somehow!) or at least inhibit any other install
> mechanisms, while the second implies that there should be a preferred,
> obvious, but not compulsory, mechanism.
>
> If you say "one and only one", and I take you at your word, then I can
> only assume that you want to actively prevent me from manually
> dropping .py files into my PYTHONPATH and having them work. I would
> guess that's probably not what you mean, but that's what it sounds like
> you're proposing. I don't like guessing -- would you please clarify
> what you mean?

one and only one way to install a distribution using its setup.py script,
among the ways provided by easy_install, distutils and pip.
e.g. avoiding having different format/location for the generated .egg.info;

>
>
> Some questions and comments regarding the PEP:
>
> Rationale:
> http://www.python.org/dev/peps/pep-0376/#id13
>
> "There are too many ways to do it."
>
> Why is having multiple ways of adding distributions a problem to be
> solved? On my Linux system, I can add packages with rpm/yum, or I can
> compile them from source and manage them myself. I possibly even could
> (but never have!) install apt-get and use it to manage packages.

If you choose not to manually manage them, the packaging system you use
is installing files in standard places where you expect to find them,
and provides
tools to know what is installed.

Right now we don't have this standard in Python stdlib to interact
with the distributions in a Python installation.  And since packaging systems
that are used out there could use the same standard, since we would like
to make distutils a reference package for this kind of need, it seems
like a good
idea to define this standard in here. then each packaging system is free
to implement its features on the top of it, ala wsgiref.

>
> Another rationale which should be added:
>
> There is no standard way of uninstalling distributions.
>
>
> How distributions are installed:
> http://www.python.org/dev/peps/pep-0376/#id14
>
> "The problem is that many people use easy_install (from the setuptools
> project [4]) or pip [5] to install their packages, and these
> third-party tools do not install packages in the same way that
> Distutils does"
>
> Why is that a problem to be solved?

Being able to retrieve the metadata of an installed distribution, or
the list of its installed files,
no matter which tool installed it.

>
>
> Uninstall information:
> http://www.python.org/dev/peps/pep-0376/#id15
>
> "Under some circumstances, you might not be able to know for sure that
> you have removed everything, or that you didn't break another
> distribution by removing a file that is shared among several
> distributions."
>
> I don't see how this proposal will help in the second case. If you
> install distribution Spam, containing file spam.py, and then install
> distribution Ham, which requires spam.py, what is to prevent you from
> removing Spam and breaking Ham?
>
> If you don't propose a solution for the dependency problem, you should
> say so.

This problem is solved as described later in the PEP, with the API
that allows you to get the
list of the distributions that use a given file. (thanks to the RECORD files)

If Spam and Ham use smap.py, and if you uninstall Spam, this file will
not be removed
because the API will tell you its used in both distributions.

>
>
> The RECORD format:
> http://www.python.org/dev/peps/pep-0376/#id19
>
> "Each record is composed of three elements.
> ...
> the MD5 hash of the file, encoded in hex. Notice that pyc and pyo
> generated files will not have a hash because they are automatically
> produced from py files."
>
> What if your distribution is not a source distribution and only provides
> pyc and pyo files?
>

Good question, I have never created such distribution.
Aren't they read-only files ? What happens if someone change them, do we
really want to keep them since it breaks the distribution ? How they
can be changed in the first place,
without the source ?

Tarek
___
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 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.
___
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 Tue, Jun 30, 2009 at 11:11 PM, Nick Coghlan wrote:
>>
>>
>> previous formats will not be supported but that won't break anything
>> of course since the new APIs will work only over the distribution
>> installed with the new version of distutils.
>
> To address PJE's question in the PEP, it may be worth expanding on this
> in the backwards compatibility section explaining how the new distutils
> metadata system avoids getting confused by the old pre-standardisation
> installation formats (e.g. it may be that the directory names and/or
> filenames all deliberately differ from current approaches precisely so
> they can coexist without interfering with each other)
>

I'll work on making it clearer,

> Also, I find the following paragraph (near the start of the section
> linked above) confusing:
>
> [PEP 376]
>> Notice that this change is based on the standard proposed by
>> EggFormats, although this standard proposes two ways to install
>> files:
>>
>> * A self-contained directory that can be zipped or left unzipped and
>> contains the distribution files and the .egg-info directory.
>> * A distinct .egg-info directory located in the site-packages directory.
>
> This is unclear as to what "this standard" is referring to (since the
> PEP itself is proposing a standard, but the sentence is also referring
> to the existing EggFormats de facto standard). If the PEP only supports
> the latter of the two options (which appears to be the case) it should
> say so explicitly.

ok

>
> Another minor nit from the same section:
>
> [PEP 376]
>> Any '-' characters are currently replaced with '_'.
>
> This should say something like "Any '-' characters other than the one in
> 'egg-info' and the one separating the name from the version number are
> included in the replacement of non-alphanumeric characters with '_'"

ok

>
> Other questions/comments:
>
> - 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,

Regards
Tarek
___
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 Tue, Jun 30, 2009 at 10:11 PM, Paul Moore wrote:
>> We said during the summit at Pycon that we wanted this feature in
>> Distutils, (Guido said so)
>
> "We" in this context denotes the people at the summit. Please remember
> that people who weren't there still have an opinion - and it may well
> differ. I'm not saying that it *does* differ, just that the view of
> the summit should not be viewed as conclusive (unless the way Python
> is developed is very different from how I understand it).

Sorry I didn't mean it this way.  The summit was just the kickoff for this PEP,
but with the strong desire to have a standard + some API for it.

Also, notice that I put in "We" also the people that answered the survey
I did before the summit.
(http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/)

I'll make other fixes in the PEP with the feedback you gave, thanks

Tarek
___
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 01:34 AM 7/1/2009 +0200, Tarek Ziadé wrote:

On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Aprano wrote:
> I don't see how this proposal will help in the second case. If you
> install distribution Spam, containing file spam.py, and then install
> distribution Ham, which requires spam.py, what is to prevent you from
> removing Spam and breaking Ham?
>
> If you don't propose a solution for the dependency problem, you should
> say so.

This problem is solved as described later in the PEP, with the API
that allows you to get the
list of the distributions that use a given file. (thanks to the RECORD files)

If Spam and Ham use smap.py, and if you uninstall Spam, this file will
not be removed
because the API will tell you its used in both distributions.


That's not the scenario he's talking about.  He's talking about the 
case where Ham has an 'install_requires' of Spam.  That is, a runtime 
dependency, not a shared file.




Good question, I have never created such distribution.
Aren't they read-only files ?


setuptools' bdist_egg command has an option to exclude source from an 
.egg, but it doesn't do anything special with permissions.  I don't 
think any other current install tools support source-free installation.


___
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 07:11 AM 7/1/2009 +1000, Nick Coghlan wrote:

To address PJE's question in the PEP, it may be worth expanding on this
in the backwards compatibility section explaining how the new distutils
metadata system avoids getting confused by the old pre-standardisation
installation formats (e.g. it may be that the directory names and/or
filenames all deliberately differ from current approaches precisely so
they can coexist without interfering with each other)


In particular, it should be explicitly noted that the API does not 
support .egg files (or directories), and thus cannot substitute for 
the pkg_resources API, as far as detecting installed packages.


That is, users who need to unequivocally detect the presence/version 
of a project on sys.path, etc. will still have to use pkg_resources.


(Because pkg_resources supports the format proposed by the PEP, but 
the PEP does not support .egg files and directories.)


___
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é]

2009/7/1 P.J. Eby :
> At 01:34 AM 7/1/2009 +0200, Tarek Ziadé wrote:
>>
>> On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Aprano
>> wrote:
>> > I don't see how this proposal will help in the second case. If you
>> > install distribution Spam, containing file spam.py, and then install
>> > distribution Ham, which requires spam.py, what is to prevent you from
>> > removing Spam and breaking Ham?
>> >
>> > If you don't propose a solution for the dependency problem, you should
>> > say so.
>>
>> This problem is solved as described later in the PEP, with the API
>> that allows you to get the
>> list of the distributions that use a given file. (thanks to the RECORD
>> files)
>>
>> If Spam and Ham use smap.py, and if you uninstall Spam, this file will
>> not be removed
>> because the API will tell you its used in both distributions.
>
> That's not the scenario he's talking about.  He's talking about the case
> where Ham has an 'install_requires' of Spam.  That is, a runtime dependency,
> not a shared file.

Ah, right sorry I misunderstood... They are no plans to handle
dependency installation / uninstallation / managment  at distutils
level.
so if you remove Ham, it will not check what distributions use it. So
yes, I'll add a note on this,

That said, the APIs will be powerfull enough for a third-party package
managers to handle this
case by throwing for example a warning or an exception.
___
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

[Kevin Teague]

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 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/archive%40mail-archive.com

Re: [Python-Dev] PEP 376

[Scott David Daniels]

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

--Scott David Daniels
scott.dani...@acm.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

[Guido van Rossum]

2009/6/30 Guido van Rossum :
> On Tue, Jun 30, 2009 at 5:32 AM, Nick Coghlan wrote:
>> Martin v. Löwis wrote:
 If no one objects, I'd like to push PEP 376 in the "accepted" status
 and go ahead with its implementation,
 with continuous feedback at Distutils-SIG as we did to build it.
>>>
>>> I think this isn't quite the process. In the past, every PEP required
>>> BDFL pronouncement, which you should now seek.
>>
>> Agreed. While Guido is highly likely to just accept the distutils-sig
>> consensus on something like this, that doesn't eliminate the need for
>> him to actually *say* that he is approving the PEP on that basis.
>
> Sure. :-)
>
> So what *is* the distutils-sig consensus?
>
> And is there consensus outside of it? (Remember the ipaddr debacle.
> It's easy for people to miss an important PEP.)

Looks like the discussion isn't quite over yet...

I did read about a third of the PEP but still feel pretty lost about
how it all fits together; I won't have time to read more until next
week, probably. I made some minor edits for typos and grammar (being
PEP editor and all :-).

I noted an inconsistency: first you say that the RECORD file uses the
excel dialect, but at the end of the same section you say it uses the
default csv settings. Sounds like you need to delete one or the other.

-- 
--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