From rwgk at yahoo.com  Sat Feb  2 07:41:34 2008
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 1 Feb 2008 22:41:34 -0800 (PST)
Subject: [Python-ideas] Namespaces are one honking great idea -- let's do
	more of those!
Message-ID: <994938.11662.qm@web31111.mail.mud.yahoo.com>

This is regarding the transition to Python 3, and the confusion caused
by using the same executable name for two incompatible interpreters.
The consequences of this struck me today when I saw this message
appear on an important bulletin board for the field I'm working in:

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=ccp4bb&T=0&F=&S=&P=1562

This posting is from a heavy-weight in the field (lookup his name with
Google or better The Web of Science). Basically he's suggesting to forget
about Python because it is an unreliable environment.

There is also this reply calling the original posting "alarmist":

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=ccp4bb&T=0&F=&S=&P=1464

And this one making fun of the whole thing:

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=ccp4bb&T=0&F=&S=&P=1675

I interpret these messages as early signs of an imminent decade of confusion.
Therefore my plea:

PLEASE GIVE THE PYTHON 3 EXECUTABLE A DIFFERENT NAME AND THE SCRIPTS
A DIFFERENT EXTENSION.

It will be a terrible political setback otherwise. Many people don't
*want* to understand even if they could. Mixing up two incompatible
interpreters under one name will give them plenty of ammunition for
cheap jokes and for defending their not-invented-here-or-before-I-was-16
attitude.

Ralf

P.S.: My wife is from Hungary. It seems all men in Hungary have to
have one of exactly three names: Andras, Laszlo, or Balazs. I never
know whom she's talking about...





From rhamph at gmail.com  Sat Feb  2 08:08:33 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Sat, 2 Feb 2008 00:08:33 -0700
Subject: [Python-ideas] Namespaces are one honking great idea -- let's
	do more of those!
In-Reply-To: <994938.11662.qm@web31111.mail.mud.yahoo.com>
References: <994938.11662.qm@web31111.mail.mud.yahoo.com>
Message-ID: <aac2c7cb0802012308i4d173c5s82ee93e313645a3@mail.gmail.com>

[bah.  Resending to the list this time.]

On Feb 1, 2008 11:41 PM, Ralf W. Grosse-Kunstleve <rwgk at yahoo.com> wrote:

> PLEASE GIVE THE PYTHON 3 EXECUTABLE A DIFFERENT NAME AND THE SCRIPTS
> A DIFFERENT EXTENSION.

We're already have half of that:

$ python2.1 -V
Python 2.1.3+
$ python2.2 -V
Python 2.2.3+
$ python2.3 -V
Python 2.3.5
$ python2.4 -V
Python 2.4.4
$ python2.5 -V
Python 2.5.1

They also have often broken python code that depended on one or two
small details, and we haven't needed a new extension before.

Now it's true that py3k will break much more than before, but I still
don't see the need to differentiate based on extension.  Installed
libraries have the version in the directory name and installed
programs should specify a version in their shebang.

The *only* issue I see is that, if you run the 2to3 tool on your
2.6-targetted codebase, it needs to output into a different directory
so that you can distinguish them.  That's so trivial that I question
even mentioning it though.

--
Adam Olsen, aka Rhamphoryncus


From guido at python.org  Sat Feb  2 12:48:57 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 2 Feb 2008 03:48:57 -0800
Subject: [Python-ideas] Namespaces are one honking great idea -- let's
	do more of those!
In-Reply-To: <994938.11662.qm@web31111.mail.mud.yahoo.com>
References: <994938.11662.qm@web31111.mail.mud.yahoo.com>
Message-ID: <ca471dc20802020348m2267f03ev7ebcc04c3a6ae0ec@mail.gmail.com>

This should be brought up on the python-3000 list; I'm moving it there
using a Bcc to python-ideas.

To some extent it is up to the vendors who distribute binaries -- they
decide what to call it.

Perhaps we should only install "python3.0" and not "python". That is a
valid choice already and always has been (python2.1, python2.2, etc.
are always installed by default, "python" is just a convenient alias).

I think that worries about Python becoming the laughingstock of the
language world are highly exaggerated. The post you refer to sounds to
me like the typical cynical one-liner from someone who doesn't really
care, not about a position of someone who is influential in the world
of language users.

--Guido

PS. Java is the VB of this decare.

On Feb 1, 2008 10:41 PM, Ralf W. Grosse-Kunstleve <rwgk at yahoo.com> wrote:
> This is regarding the transition to Python 3, and the confusion caused
> by using the same executable name for two incompatible interpreters.
> The consequences of this struck me today when I saw this message
> appear on an important bulletin board for the field I'm working in:
>
> http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=ccp4bb&T=0&F=&S=&P=1562
>
> This posting is from a heavy-weight in the field (lookup his name with
> Google or better The Web of Science). Basically he's suggesting to forget
> about Python because it is an unreliable environment.
>
> There is also this reply calling the original posting "alarmist":
>
> http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=ccp4bb&T=0&F=&S=&P=1464
>
> And this one making fun of the whole thing:
>
> http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=ccp4bb&T=0&F=&S=&P=1675
>
> I interpret these messages as early signs of an imminent decade of confusion.
> Therefore my plea:
>
> PLEASE GIVE THE PYTHON 3 EXECUTABLE A DIFFERENT NAME AND THE SCRIPTS
> A DIFFERENT EXTENSION.
>
> It will be a terrible political setback otherwise. Many people don't
> *want* to understand even if they could. Mixing up two incompatible
> interpreters under one name will give them plenty of ammunition for
> cheap jokes and for defending their not-invented-here-or-before-I-was-16
> attitude.
>
> Ralf
>
> P.S.: My wife is from Hungary. It seems all men in Hungary have to
> have one of exactly three names: Andras, Laszlo, or Balazs. I never
> know whom she's talking about...
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



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


From greg.ewing at canterbury.ac.nz  Sat Feb  2 23:42:29 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 03 Feb 2008 11:42:29 +1300
Subject: [Python-ideas] Namespaces are one honking great idea -- let's
 do more of those!
In-Reply-To: <aac2c7cb0802012308i4d173c5s82ee93e313645a3@mail.gmail.com>
References: <994938.11662.qm@web31111.mail.mud.yahoo.com>
	<aac2c7cb0802012308i4d173c5s82ee93e313645a3@mail.gmail.com>
Message-ID: <47A4F1D5.5080405@canterbury.ac.nz>

Adam Olsen wrote:
> They also have often broken python code that depended on one or two
> small details, and we haven't needed a new extension before.

But we haven't had such major incompatibilities
between versions before.

At the least, I think the executable should only
be installed as "python3", and never just "python"
(unless you know what you're doing and ask for it).

--
Greg


From stephen at xemacs.org  Sun Feb  3 02:24:31 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 03 Feb 2008 10:24:31 +0900
Subject: [Python-ideas] Namespaces are one honking great idea -- let's
 do more of those!
In-Reply-To: <47A4F1D5.5080405@canterbury.ac.nz>
References: <994938.11662.qm@web31111.mail.mud.yahoo.com>
	<aac2c7cb0802012308i4d173c5s82ee93e313645a3@mail.gmail.com>
	<47A4F1D5.5080405@canterbury.ac.nz>
Message-ID: <87oday96i8.fsf@uwakimon.sk.tsukuba.ac.jp>

Guido asked that this thread be moved to python-3000.  Reply-To set.

Greg Ewing writes:

 > Adam Olsen wrote:
 > > They also have often broken python code that depended on one or two
 > > small details, and we haven't needed a new extension before.
 > 
 > But we haven't had such major incompatibilities
 > between versions before.
 > 
 > At the least, I think the executable should only
 > be installed as "python3", and never just "python"
 > (unless you know what you're doing and ask for it).

I don't see any need to shorten "python3.0" to "python3".

Also, another exception should be if there is no other Python
installed.  Then installing a link at "python" should be OK.



From adam at atlas.st  Wed Feb  6 00:39:17 2008
From: adam at atlas.st (Adam Atlas)
Date: Tue, 5 Feb 2008 18:39:17 -0500
Subject: [Python-ideas] [Web-SIG] Merge Cookie and cookielib?
In-Reply-To: <bbaeab100802051521y2debfbbay17fe9bd806cfbe50@mail.gmail.com>
References: <bbaeab100802051521y2debfbbay17fe9bd806cfbe50@mail.gmail.com>
Message-ID: <1DF7B1D6-D271-4794-9871-AF9BBEC74EC2@atlas.st>

(This is from a discussion taking place on Web-SIG, but this isn't web- 
related, so I'm sending it to python-ideas.)


On 5 Feb 2008, at 18:21, Brett Cannon wrote:
> My current idea is the new names cookie.client and cookie.server for
> Cookie and cookielib, respectively. While this goes against the goal
> of making the new names easier to work with, Cookie has to be renamed
> because of its PEP 8 violation. And having cookie and cookielib in the
> stdlib will not help with differentiating between the two.

Has anyone proposed dropping the -lib suffix on *all* modules that  
currently use it? It annoys me. It seems arbitrary and redundant.

I suppose there must be some historical reason for that, but I can't  
imagine it would still be very relevant.


From santagada at gmail.com  Wed Feb  6 01:11:31 2008
From: santagada at gmail.com (Leonardo Santagada)
Date: Tue, 5 Feb 2008 22:11:31 -0200
Subject: [Python-ideas] [Web-SIG] Merge Cookie and cookielib?
In-Reply-To: <1DF7B1D6-D271-4794-9871-AF9BBEC74EC2@atlas.st>
References: <bbaeab100802051521y2debfbbay17fe9bd806cfbe50@mail.gmail.com>
	<1DF7B1D6-D271-4794-9871-AF9BBEC74EC2@atlas.st>
Message-ID: <BC1F45CA-2421-41A2-B077-710E57697308@gmail.com>


On 05/02/2008, at 21:39, Adam Atlas wrote:
> On 5 Feb 2008, at 18:21, Brett Cannon wrote:
>> My current idea is the new names cookie.client and cookie.server for
>> Cookie and cookielib, respectively. While this goes against the goal
>> of making the new names easier to work with, Cookie has to be renamed
>> because of its PEP 8 violation. And having cookie and cookielib in  
>> the
>> stdlib will not help with differentiating between the two.

I like this, but maybe it goes against some notion of a shallow stdlib  
namespace... so maybe cookieclient and cookieserver or something is  
better.

> Has anyone proposed dropping the -lib suffix on *all* modules that
> currently use it? It annoys me. It seems arbitrary and redundant.

how would you call httplib? httpclient I guess.

+50 if I could vote.


--
Leonardo Santagada





From brett at python.org  Wed Feb  6 01:30:51 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 5 Feb 2008 16:30:51 -0800
Subject: [Python-ideas] [Web-SIG] Merge Cookie and cookielib?
In-Reply-To: <1DF7B1D6-D271-4794-9871-AF9BBEC74EC2@atlas.st>
References: <bbaeab100802051521y2debfbbay17fe9bd806cfbe50@mail.gmail.com>
	<1DF7B1D6-D271-4794-9871-AF9BBEC74EC2@atlas.st>
Message-ID: <bbaeab100802051630m2f96bea2n89bbafecc2522ded@mail.gmail.com>

On Feb 5, 2008 3:39 PM, Adam Atlas <adam at atlas.st> wrote:
> (This is from a discussion taking place on Web-SIG, but this isn't web-
> related, so I'm sending it to python-ideas.)
>

This should be on stdlib-sig. If you actually want to propose it,
bring it up there.

-Brett


From brett at python.org  Wed Feb  6 01:32:16 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 5 Feb 2008 16:32:16 -0800
Subject: [Python-ideas] [Web-SIG] Merge Cookie and cookielib?
In-Reply-To: <BC1F45CA-2421-41A2-B077-710E57697308@gmail.com>
References: <bbaeab100802051521y2debfbbay17fe9bd806cfbe50@mail.gmail.com>
	<1DF7B1D6-D271-4794-9871-AF9BBEC74EC2@atlas.st>
	<BC1F45CA-2421-41A2-B077-710E57697308@gmail.com>
Message-ID: <bbaeab100802051632s349458e6p6b3f2719245ce2f9@mail.gmail.com>

On Feb 5, 2008 4:11 PM, Leonardo Santagada <santagada at gmail.com> wrote:
>
> On 05/02/2008, at 21:39, Adam Atlas wrote:
> > On 5 Feb 2008, at 18:21, Brett Cannon wrote:
> >> My current idea is the new names cookie.client and cookie.server for
> >> Cookie and cookielib, respectively. While this goes against the goal
> >> of making the new names easier to work with, Cookie has to be renamed
> >> because of its PEP 8 violation. And having cookie and cookielib in
> >> the
> >> stdlib will not help with differentiating between the two.
>
> I like this, but maybe it goes against some notion of a shallow stdlib
> namespace... so maybe cookieclient and cookieserver or something is
> better.
>

No it doesn't go against that idea as it is a single level.

> > Has anyone proposed dropping the -lib suffix on *all* modules that
> > currently use it? It annoys me. It seems arbitrary and redundant.
>
> how would you call httplib? httpclient I guess.
>
> +50 if I could vote.

Any stdlib reorg talk should happen on stdlib-sig. Please take it over
there (and if you do read PEP 3108 and the archives as httplib has
already been handled).

-Brett


From python at rcn.com  Sun Feb 10 02:22:43 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sat, 9 Feb 2008 17:22:43 -0800
Subject: [Python-ideas] Idea for the mapping API
Message-ID: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>

Perhaps, the dict() constructor should accept any object with a __dict__ method.

The principle is that almost any object that has key and value pairs (named tuples for example) should be readily convertable to and 
from a dictionary.  The current, non-uniform alternative is for the object to provide an asdict() method and for the user to call it 
directly.


Raymond


From adam at atlas.st  Sun Feb 10 03:05:55 2008
From: adam at atlas.st (Adam Atlas)
Date: Sat, 9 Feb 2008 21:05:55 -0500
Subject: [Python-ideas] Idea for the mapping API
In-Reply-To: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>
References: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>
Message-ID: <6C338C55-A294-4ECA-9268-8DFF86D42C92@atlas.st>


On 9 Feb 2008, at 20:22, Raymond Hettinger wrote:
> Perhaps, the dict() constructor should accept any object with a  
> __dict__ method.
>
> The principle is that almost any object that has key and value pairs  
> (named tuples for example) should be readily convertable to and
> from a dictionary.  The current, non-uniform alternative is for the  
> object to provide an asdict() method and for the user to call it
> directly.

I think the upcoming Abstract Base Classes support will take care of  
this... a dict-like class can register with the Mapping base class (or  
whatever it is to be called), and that could signal the dict()  
constructor to check for items() and use that if it's available.

Your way would confuse things somewhat, because that's not really what  
__dict__ signifies. Suppose you subclass `dict` and give it some  
attributes. Their values will be stored in the instance's __dict__,  
while any keys set on the instance (i.e. __setitem__ not __setattr__)  
will not. In general, I think it's best to keep attributes and mapping  
contents cleanly separated; I don't think it would be good if dict()  
implicitly became a somewhat unpredictable near-clone of vars().


From ryan.freckleton at gmail.com  Sun Feb 10 03:41:27 2008
From: ryan.freckleton at gmail.com (Ryan Freckleton)
Date: Sat, 9 Feb 2008 19:41:27 -0700
Subject: [Python-ideas] Idea for the mapping API
In-Reply-To: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>
References: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>
Message-ID: <318072440802091841p277f09c0h1d9d53f544f2800f@mail.gmail.com>

I'd rather have the dict built-in function be a dynamically
over-loadable (generic) function. I think it's a better fit than
adding another __special__ method. The same technique could be used
for the other built-in types and user created classes.

Somewhat similar to Eiffel, actually...

On Feb 9, 2008 6:22 PM, Raymond Hettinger <python at rcn.com> wrote:
> Perhaps, the dict() constructor should accept any object with a __dict__ method.
>
> The principle is that almost any object that has key and value pairs (named tuples for example) should be readily convertable to and
> from a dictionary.  The current, non-uniform alternative is for the object to provide an asdict() method and for the user to call it
> directly.
>
>
> Raymond
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
=====
--Ryan E. Freckleton


From guido at python.org  Sun Feb 10 03:34:39 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 9 Feb 2008 18:34:39 -0800
Subject: [Python-ideas] Idea for the mapping API
In-Reply-To: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>
References: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>
Message-ID: <ca471dc20802091834n63f6570ck3173a6ac0ae9a8b6@mail.gmail.com>

On Feb 9, 2008 5:22 PM, Raymond Hettinger <python at rcn.com> wrote:
> Perhaps, the dict() constructor should accept any object with a __dict__ method.

Won't that interfere with the existing __dict__ *attribute* of most
objects (e.g. modules)?

> The principle is that almost any object that has key and value pairs (named tuples for example) should be readily convertable to and
> from a dictionary.  The current, non-uniform alternative is for the object to provide an asdict() method and for the user to call it
> directly.

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


From rnd at onego.ru  Sun Feb 10 19:31:30 2008
From: rnd at onego.ru (Roman Susi)
Date: Sun, 10 Feb 2008 20:31:30 +0200
Subject: [Python-ideas] Storages Re:  Idea for the mapping API
In-Reply-To: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>
References: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>
Message-ID: <47AF4302.9060007@onego.ru>

Raymond Hettinger wrote:
> Perhaps, the dict() constructor should accept any object with a __dict__ method.
> 
> The principle is that almost any object that has key and value pairs (named tuples for example) should be readily convertable to and 
> from a dictionary.  The current, non-uniform alternative is for the object to provide an asdict() method and for the user to call it 
> directly.
> 
> Raymond

BTW, will the coming ABC have classes with "setattr ~= setitem"
functionality? Yes, its quite easy to do (docstring from web.py
utils.Storage is not longer than implementation):

    """
    A Storage object is like a dictionary except `obj.foo` can be used
    in addition to `obj['foo']`.

        >>> o = storage(a=1)
        >>> o.a
        1
        >>> o['a']
        1
        >>> o.a = 2
        >>> o['a']
        2
        >>> del o.a
        >>> o.a
        Traceback (most recent call last):
            ...
        AttributeError: 'a'

    """

At least, this could set the bare protocol of such hybrid for anyone to
subclass.


-Roman


From guido at python.org  Sun Feb 10 20:27:18 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 10 Feb 2008 11:27:18 -0800
Subject: [Python-ideas] Storages Re: Idea for the mapping API
In-Reply-To: <47AF4302.9060007@onego.ru>
References: <007601c86b83$6ffc4270$6800a8c0@RaymondLaptop1>
	<47AF4302.9060007@onego.ru>
Message-ID: <ca471dc20802101127p43eaf202jf30a0fb4a82836bb@mail.gmail.com>

On Feb 10, 2008 10:31 AM, Roman Susi <rnd at onego.ru> wrote:
> Raymond Hettinger wrote:
> > Perhaps, the dict() constructor should accept any object with a __dict__ method.
> >
> > The principle is that almost any object that has key and value pairs (named tuples for example) should be readily convertable to and
> > from a dictionary.  The current, non-uniform alternative is for the object to provide an asdict() method and for the user to call it
> > directly.
> >
> > Raymond
>
> BTW, will the coming ABC have classes with "setattr ~= setitem"
> functionality?

No-- this will just cause confusion about which API to use. Go use
JavaScript if you want that. :-)

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


From bjourne at gmail.com  Wed Feb 20 16:22:46 2008
From: bjourne at gmail.com (=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=)
Date: Wed, 20 Feb 2008 16:22:46 +0100
Subject: [Python-ideas] exit as a statement
Message-ID: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>

An idea I have thought about for a while and it makes sense to me...

$ python
Python 2.4.2 (#1, Oct 13 2006, 17:17:08)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exit
'Use Ctrl-D (i.e. EOF) to exit.'

Argh! Do what I mean, stupid Python! And it is Ctrl+Z on Windows, not
Ctrl-D. So exit could be a statement that does the same thing that
sys.exit() does currently. Bare "exit" to terminate with return code
0, and "exit X" to terminate with return code X.


-- 
mvh Bj?rn


From guido at python.org  Wed Feb 20 16:45:59 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 20 Feb 2008 07:45:59 -0800
Subject: [Python-ideas] exit as a statement
In-Reply-To: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
References: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
Message-ID: <ca471dc20802200745p68bfb8aclb2ca956dd957c025@mail.gmail.com>

This goes against the idea of keeping the language small. Believe me,
it's been discussed to death, and the behavior you see now is the
solid outcome of that discussion.

On Feb 20, 2008 7:22 AM, BJ?rn Lindqvist <bjourne at gmail.com> wrote:
> An idea I have thought about for a while and it makes sense to me...
>
> $ python
> Python 2.4.2 (#1, Oct 13 2006, 17:17:08)
> [GCC 4.1.0 (SUSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> exit
> 'Use Ctrl-D (i.e. EOF) to exit.'
>
> Argh! Do what I mean, stupid Python! And it is Ctrl+Z on Windows, not
> Ctrl-D. So exit could be a statement that does the same thing that
> sys.exit() does currently. Bare "exit" to terminate with return code
> 0, and "exit X" to terminate with return code X.
>
>
> --
> mvh Bj?rn
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



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


From aahz at pythoncraft.com  Wed Feb 20 16:57:15 2008
From: aahz at pythoncraft.com (Aahz)
Date: Wed, 20 Feb 2008 07:57:15 -0800
Subject: [Python-ideas] exit as a statement
In-Reply-To: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
References: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
Message-ID: <20080220155715.GA23797@panix.com>

On Wed, Feb 20, 2008, BJ?rn Lindqvist wrote:
>
> An idea I have thought about for a while and it makes sense to me...
> 
> $ python
> Python 2.4.2 (#1, Oct 13 2006, 17:17:08)
> [GCC 4.1.0 (SUSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> exit
> 'Use Ctrl-D (i.e. EOF) to exit.'
> 
> Argh! Do what I mean, stupid Python! And it is Ctrl+Z on Windows, not
> Ctrl-D. So exit could be a statement that does the same thing that
> sys.exit() does currently. Bare "exit" to terminate with return code
> 0, and "exit X" to terminate with return code X.

Python 2.5.1 (r251:54863, Sep 27 2007, 12:17:47) 
[GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd3
Type "help", "copyright", "credits" or "license" for more information.
>>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit
>>> exit()
%

This is essential because we do NOT want to add a new statement; however,
we can make ``exit`` an object with a repr() that tells people to call
it.  IIRC, on Windows, it does say "Ctrl-Z" -- but it doesn't matter,
because IIRC Ctrl-D does work on Windows.  (I won't bother to fire up my
Windows box to check.)

In theory, we could make ``exit`` a property() that raises SystemExit,
but that seems to magical for my taste (and other people agreed).
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson


From ironfroggy at socialserve.com  Wed Feb 20 16:51:56 2008
From: ironfroggy at socialserve.com (Calvin Spealman)
Date: Wed, 20 Feb 2008 10:51:56 -0500
Subject: [Python-ideas] exit as a statement
In-Reply-To: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
References: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
Message-ID: <2C791209-BE2E-4211-8EE1-94CB55527E9B@socialserve.com>

This has been discussed to death several times before. I remember the  
rationale against doing something different to have various reasons.  
No one likes adding statements, for one thing (we have a tendency to  
move things out of keyword-space, not into it). Another solution was  
to define an ExitType with __str__ defined to raise SystemExit, but  
then what happens if you just do something to dump a bunch of  
objects? In other words: a side effect exiting is dangerous.

As far as an actual statement, I'd definitely be -1 with a single  
exception. Would it be possible to define exit as an interpreter  
command, so long as the name 'exit' is not bound to anything but the  
exit str? In other words, it would only actually exit when you are in  
the interpreter, not when executing scripts or modules.

On Feb 20, 2008, at 10:22 AM, BJ?rn Lindqvist wrote:

> An idea I have thought about for a while and it makes sense to me...
>
> $ python
> Python 2.4.2 (#1, Oct 13 2006, 17:17:08)
> [GCC 4.1.0 (SUSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> exit
> 'Use Ctrl-D (i.e. EOF) to exit.'
>
> Argh! Do what I mean, stupid Python! And it is Ctrl+Z on Windows, not
> Ctrl-D. So exit could be a statement that does the same thing that
> sys.exit() does currently. Bare "exit" to terminate with return code
> 0, and "exit X" to terminate with return code X.
>
>
> -- 
> mvh Bj?rn
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



From lists at cheimes.de  Wed Feb 20 17:10:50 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 20 Feb 2008 17:10:50 +0100
Subject: [Python-ideas] exit as a statement
In-Reply-To: <20080220155715.GA23797@panix.com>
References: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
	<20080220155715.GA23797@panix.com>
Message-ID: <fphjea$ad1$1@ger.gmane.org>

Aahz wrote:
> This is essential because we do NOT want to add a new statement; however,
> we can make ``exit`` an object with a repr() that tells people to call
> it.  IIRC, on Windows, it does say "Ctrl-Z" -- but it doesn't matter,
> because IIRC Ctrl-D does work on Windows.  (I won't bother to fire up my
> Windows box to check.)
> 
> In theory, we could make ``exit`` a property() that raises SystemExit,
> but that seems to magical for my taste (and other people agreed).

You are right and you are wrong. :] On Windows the repr of the exit
object says the right thing. But CTRL+D <enter> doesn't work on Windows.
Only CTRL+Z <enter> works.

Python 2.6a0 (trunk-math:60904M, Feb 19 2008, 17:58:34) [MSC v.1500 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit
Use exit() or Ctrl-Z plus Return to exit
>>> ^D
  File "<stdin>", line 1
    ?
    ^
SyntaxError: invalid syntax
>>> ^Z


Christian



From bjourne at gmail.com  Wed Feb 20 17:45:07 2008
From: bjourne at gmail.com (=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=)
Date: Wed, 20 Feb 2008 17:45:07 +0100
Subject: [Python-ideas] exit as a statement
In-Reply-To: <2C791209-BE2E-4211-8EE1-94CB55527E9B@socialserve.com>
References: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
	<2C791209-BE2E-4211-8EE1-94CB55527E9B@socialserve.com>
Message-ID: <740c3aec0802200845w3055d1acq4766e486ed70c4ff@mail.gmail.com>

On Wed, Feb 20, 2008 at 4:51 PM, Calvin Spealman
<ironfroggy at socialserve.com> wrote:
> This has been discussed to death several times before. I remember the
>  rationale against doing something different to have various reasons.

I haven't seem the statement idea discussed before.

>  No one likes adding statements, for one thing (we have a tendency to
>  move things out of keyword-space, not into it).

What would the disadvantages of adding exit as a statement be? Would
it make Python worse? Is there any other non-magical and
straightforward solution to make exit to "do what I mean"?


-- 
mvh Bj?rn


From george.sakkis at gmail.com  Wed Feb 20 18:03:17 2008
From: george.sakkis at gmail.com (George Sakkis)
Date: Wed, 20 Feb 2008 12:03:17 -0500
Subject: [Python-ideas] exit as a statement
In-Reply-To: <740c3aec0802200845w3055d1acq4766e486ed70c4ff@mail.gmail.com>
References: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
	<2C791209-BE2E-4211-8EE1-94CB55527E9B@socialserve.com>
	<740c3aec0802200845w3055d1acq4766e486ed70c4ff@mail.gmail.com>
Message-ID: <91ad5bf80802200903x776cbce5g17d435efa4f0f1e0@mail.gmail.com>

On Feb 20, 2008 11:45 AM, BJ?rn Lindqvist <bjourne at gmail.com> wrote:

> What would the disadvantages of adding exit as a statement be? Would
> it make Python worse? Is there any other non-magical and
> straightforward solution to make exit to "do what I mean"?

I hear you.. I keep typing
exit_now_you_stupid_excuse_of_an_interpreter but it doesn't do what I
mean!

Seriously, pressing Ctrl-D/Ctrl-Z is not that much of a trouble to
justify the bandwidth used for this thread.

George


From lists at cheimes.de  Wed Feb 20 18:07:05 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 20 Feb 2008 18:07:05 +0100
Subject: [Python-ideas] exit as a statement
In-Reply-To: <740c3aec0802200845w3055d1acq4766e486ed70c4ff@mail.gmail.com>
References: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>	<2C791209-BE2E-4211-8EE1-94CB55527E9B@socialserve.com>
	<740c3aec0802200845w3055d1acq4766e486ed70c4ff@mail.gmail.com>
Message-ID: <fphmnq$trp$1@ger.gmane.org>

BJ?rn Lindqvist wrote:
> What would the disadvantages of adding exit as a statement be? Would
> it make Python worse? Is there any other non-magical and
> straightforward solution to make exit to "do what I mean"?

We are trying hard to reduce the amount of statements and builtins. exit
as a statement isn't worth the extra code. There are already plenty of
ways to exit an interpreter process:

sys.exit()
os._exit()
raise SystemExit
exit() (interactive prompt)
CTRL+Z or CTRL+D (interactive prompt)

Christian



From phd at phd.pp.ru  Wed Feb 20 19:06:01 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Wed, 20 Feb 2008 21:06:01 +0300
Subject: [Python-ideas] exit as a statement
In-Reply-To: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
References: <740c3aec0802200722m27c94061w11d8b6e3cc03aec8@mail.gmail.com>
Message-ID: <20080220180601.GB5180@phd.pp.ru>

On Wed, Feb 20, 2008 at 04:22:46PM +0100, BJ?rn Lindqvist wrote:
> exit could be a statement that does the same thing that
> sys.exit() does currently. Bare "exit" to terminate with return code
> 0, and "exit X" to terminate with return code X.

http://phd.pp.ru/Software/dotfiles/init.py.html

   See class _Exit.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.


From arne_bab at web.de  Fri Feb 22 09:53:32 2008
From: arne_bab at web.de (Arne Babenhauserheide)
Date: Fri, 22 Feb 2008 09:53:32 +0100
Subject: [Python-ideas] simpler super() syntax
Message-ID: <200802220953.32787.arne_bab@web.de>

Hi, 

I just spent some time figuring out how and why super needs to be called with 
*args and **kwds in any class, when I use multiple inheritance (or when some 
subclass wants to use it), and I got the impression, that simply every class 
should take *args and **kwds and that super should be called inside the init 
of every class. 

Would it make sense to make the init of any class take *args and **kwds 
implicitely? 

With that, arguments and keywords would always be passed on (the behaviour we 
need as soon as we use any multiple inheritance) and the code would look 
cleaner (I think). 


At the moment the code for a class with MI looks like this: 

class Blah(Blubb): 
	def __init__(*args, **kwds)
		super(Blah, self).__init__(*args, **kwds)

with implicit *args and **kwds, it would look like this: 

class Blah(Blubb): 
	def __init__()
		super(Blah, self).__init__()

And by calling super, I implicitely say, that i want to pass on any leftover 
args or kwds which (to my knowledge) I must do anyway, since else I am in 
danger of getting MI bugs. 

What do you think? 

Best wishes, 
Arne
-- 
Unpolitisch sein
Hei?t politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )
-- Weblog: http://blog.draketo.de

-- Mein ?ffentlicher Schl?ssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20080222/db049c66/attachment.pgp>

From szekeres at iii.hu  Fri Feb 22 12:30:35 2008
From: szekeres at iii.hu (=?UTF-8?Q?Szekeres_Istv=C3=A1n?=)
Date: Fri, 22 Feb 2008 12:30:35 +0100
Subject: [Python-ideas] simpler super() syntax
In-Reply-To: <200802220953.32787.arne_bab@web.de>
References: <200802220953.32787.arne_bab@web.de>
Message-ID: <f4fe1c2a0802220330q12df2007pd2e216d393ee5783@mail.gmail.com>

Hi,

At the moment the code for a class with MI looks like this:
>
> class Blah(Blubb):
>        def __init__(*args, **kwds)
>                super(Blah, self).__init__(*args, **kwds)
>
> with implicit *args and **kwds, it would look like this:
>
> class Blah(Blubb):
>        def __init__()
>                super(Blah, self).__init__()
>
> And by calling super, I implicitely say, that i want to pass on any
> leftover
> args or kwds which (to my knowledge) I must do anyway, since else I am in
> danger of getting MI bugs.
>

>From Blah.__init__ how would you call super(Blah, self).__init__ if you
explicitely do not want to pass any arguments to it?

super(Blah, self).__init(*[],**{})   ? :)

If your only concern is that you have to type "*args, **kwds" too many
times, maybe something the following could be introduced:

def __init__(*):
   super(Blah, self).__init__(*)

so * would mean whatever argument is given to the function.

Or we similarly to *args and **kwds possibly the new syntax ***allargs could
be introduced which would mean a tuple of *args and **kwds. That could be
abbreviated as ***a    -> it is much sorter and easier to type, yet it is
implicit.

Istvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20080222/266efde5/attachment.html>

From guido at python.org  Fri Feb 22 17:12:31 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 22 Feb 2008 08:12:31 -0800
Subject: [Python-ideas] simpler super() syntax
In-Reply-To: <200802220953.32787.arne_bab@web.de>
References: <200802220953.32787.arne_bab@web.de>
Message-ID: <ca471dc20802220812m1c645146p389311ae13fa34d5@mail.gmail.com>

(a) In Py3k, you will be able to use super() itself without args, e.g.
super().__init__(*args)

(b) There are lots of reasons why you would not want to pass the args
to your super method *unchanged*. Also, super methods may have
defaults for all args. So super.__init__() would be ambiguous -- does
he want to pass all args or none?

Because of this I am strongly against this.

On Fri, Feb 22, 2008 at 12:53 AM, Arne Babenhauserheide <arne_bab at web.de> wrote:
> Hi,
>
>  I just spent some time figuring out how and why super needs to be called with
>  *args and **kwds in any class, when I use multiple inheritance (or when some
>  subclass wants to use it), and I got the impression, that simply every class
>  should take *args and **kwds and that super should be called inside the init
>  of every class.
>
>  Would it make sense to make the init of any class take *args and **kwds
>  implicitely?
>
>  With that, arguments and keywords would always be passed on (the behaviour we
>  need as soon as we use any multiple inheritance) and the code would look
>  cleaner (I think).
>
>
>  At the moment the code for a class with MI looks like this:
>
>  class Blah(Blubb):
>         def __init__(*args, **kwds)
>                 super(Blah, self).__init__(*args, **kwds)
>
>  with implicit *args and **kwds, it would look like this:
>
>  class Blah(Blubb):
>         def __init__()
>                 super(Blah, self).__init__()
>
>  And by calling super, I implicitely say, that i want to pass on any leftover
>  args or kwds which (to my knowledge) I must do anyway, since else I am in
>  danger of getting MI bugs.
>
>  What do you think?
>
>  Best wishes,
>  Arne
>  --
>  Unpolitisch sein
>  Hei?t politisch sein
>  Ohne es zu merken.
>  - Arne Babenhauserheide ( http://draketo.de )
>  -- Weblog: http://blog.draketo.de
>
>  -- Mein ?ffentlicher Schl?ssel (PGP/GnuPG):
>  http://draketo.de/inhalt/ich/pubkey.txt
>
> _______________________________________________
>  Python-ideas mailing list
>  Python-ideas at python.org
>  http://mail.python.org/mailman/listinfo/python-ideas
>
>



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