From shane.holloway at ieee.org  Fri Jul  1 00:04:51 2005
From: shane.holloway at ieee.org (Shane Holloway (IEEE))
Date: Thu, 30 Jun 2005 16:04:51 -0600
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API for
 sets.Set and build-in set)
In-Reply-To: <000a01c57dba$520e8700$1330cb97@oemcomputer>
References: <000a01c57dba$520e8700$1330cb97@oemcomputer>
Message-ID: <42C46C83.8060604@ieee.org>

Raymond Hettinger wrote:
> I would think that that generic clearing is a lark.  First, it only
> applies to mutable objects.  Second, it would likely only be useful in
> the presence of a generic method for adding to the cleared container (as
> opposed to the existing append(), add(), and setitem() methods for
> lists, sets, and dictionaries respectively).  So, for lists, stick with
> the current idiom:
> 
>    mylist[:] = []       # clear

Pros of list.clear:
 + easy to find in documentation and help()
 + readability & clarity of intention in code
 + commonality with other mutable collections
 + easier to search on "clear()" (well, at least for me...)

Cons of list.clear:
 + Yet another method on list
 + Three ways to do the same thing.
     mylist[:] = []
     del mylist[:]
     mylist.clear()

     (Although the implementation will use one of slice operators,
so I guess that depends on how you count ;)


I would agree generic clearing is a lark in terms of programming
feature.  However, I have been asked how to clear a list more than a
handful of times.  Personally, my opinion is that having a
list.clear method would be a net win, especially since the
implementation can be implemented via __setitem__ or __delitem__.

Are there more Cons than those I have listed?

From tim.peters at gmail.com  Fri Jul  1 00:20:38 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 30 Jun 2005 18:20:38 -0400
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API for
	sets.Set and build-in set)
In-Reply-To: <200506301743.32417.fdrake@acm.org>
References: <000a01c57dba$520e8700$1330cb97@oemcomputer>
	<200506301743.32417.fdrake@acm.org>
Message-ID: <1f7befae05063015207acb85dc@mail.gmail.com>

[Raymond Hettinger]
>> the current idiom:
>>
>>    mylist[:] = []       # clear

[Fred L. Drake, Jr.]
> Unless you happen to prefer the other current idiom:
>
>    del mylist[:]

Or my personal favorite,

    while mylist:
        del mylist[::2]

Then the original index positions with the most consecutive trailing 1
bits survive the longest, which is important to avoid ZODB cache bugs
<wink>.

From python at rcn.com  Fri Jul  1 00:35:51 2005
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 30 Jun 2005 18:35:51 -0400
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API for
	sets.Set and build-in set)
In-Reply-To: <42C46C83.8060604@ieee.org>
Message-ID: <001701c57dc4$12468280$1330cb97@oemcomputer>

[Shane Holloway]
> I would agree generic clearing is a lark in terms of programming
> feature.  However, I have been asked how to clear a list more than a
> handful of times. 

list.clear() does not solve the root problem.  The question is
symptomatic of not understanding slicing.  Avoidance of that knowledge
doesn't help the person at all.  Slicing is part of Python 101 and is
basic to the language.  There is a reason this subject is presented
right at the beginning of the tutorial.

By the time a person is writing apps that modify lists in-place
(clearing and rebuilding), then they need to know how lists work.  So, a
better solution is to submit a doc patch to improve the tutorial's
presentation on the subject.

IMO, there is a much stronger case for Fredrik's proposed join()
builtin.  That addresses an issue that feels warty on the first day you
learn it and still feels that way years later.


Raymond

From mwh at python.net  Fri Jul  1 00:54:25 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 30 Jun 2005 23:54:25 +0100
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000d01c57dbc$71df2420$1330cb97@oemcomputer> (Raymond
	Hettinger's message of "Thu, 30 Jun 2005 17:41:16 -0400")
References: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
Message-ID: <2macl7xxpa.fsf@starship.python.net>

"Raymond Hettinger" <raymond.hettinger at verizon.net> writes:

> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
>
> What term should describe those objects in the documentation?  

Hmm, don't know.

I talked about an object 'that conformed to the with protocol' at
EuroPython, which seems about right -- but is hardly an adjective!

Guard?  Monitor?  Don't really like either of these.

Cheers,
mwh

-- 
  <warner> my worst nightmares involve the alarm clock only 
           ringing on mornings after I fall asleep on minutes
           ending in an even number             -- from Twisted.Quotes

From bcannon at gmail.com  Fri Jul  1 01:03:48 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 30 Jun 2005 16:03:48 -0700
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
References: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
Message-ID: <bbaeab1005063016033044ad1a@mail.gmail.com>

"Resource managed"?

On 6/30/05, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
> 
> What term should describe those objects in the documentation?
> 
> For instance, if the new magic methods are added to decimal.Context(),
> do we then describe Context objects as "withable" ;-)
> 
> The PEP itself doesn't provide much of a clue.  The terms "template",
> "wrapper", and "block" are over-broad and do not provide a metaphor for
> setup/teardown, r entry/exit, or initialization/finalization.
> 
> Whatever term is selected, it should be well thought-out and added to
> the glossary.  The choice of words will likely have a great effect on
> learnability and on how people think about the new tool.
> 
> 
> Raymond
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>

From nidoizo at yahoo.com  Fri Jul  1 01:23:11 2005
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Thu, 30 Jun 2005 19:23:11 -0400
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API for
 sets.Set and build-in set)
In-Reply-To: <000a01c57dba$520e8700$1330cb97@oemcomputer>
References: <da1bnm$m0k$1@sea.gmane.org>
	<000a01c57dba$520e8700$1330cb97@oemcomputer>
Message-ID: <da1u8v$9nf$1@sea.gmane.org>

Raymond Hettinger wrote:
> Use copy.copy() for generic copying -- it works across a wide range of
> objects.  Alternatively, use the constructor as generic way to make
> duplicates:
> 
>    dup = set(s)
>    dup = list(l)
>    dup = dict(d)
>    dup = tuple(t)     # note, the duplicate is original object here :-)

I know all this, but why then is there a copy method for sets and 
dictionaries?  What justification is valid for sets and dictionaries 
that doesn't apply to lists?

Regards,
Nicolas


From nidoizo at yahoo.com  Fri Jul  1 01:36:09 2005
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Thu, 30 Jun 2005 19:36:09 -0400
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API for
 sets.Set and build-in set)
In-Reply-To: <001701c57dc4$12468280$1330cb97@oemcomputer>
References: <42C46C83.8060604@ieee.org>
	<001701c57dc4$12468280$1330cb97@oemcomputer>
Message-ID: <da1v19$bek$1@sea.gmane.org>

Raymond Hettinger wrote:
> [Shane Holloway]
> 
>>I would agree generic clearing is a lark in terms of programming
>>feature.  However, I have been asked how to clear a list more than a
>>handful of times. 
> 
> list.clear() does not solve the root problem.  The question is
> symptomatic of not understanding slicing.  Avoidance of that knowledge
> doesn't help the person at all.  Slicing is part of Python 101 and is
> basic to the language.  There is a reason this subject is presented
> right at the beginning of the tutorial.

I tend to not agree.  I don't think it is symptomatic of "not 
understanding slicing", but instead of "not being in a slicing state of 
mind".  What I see in day-to-day is that when programmers want to clear 
a list, they are sometimes in a situation where you have some persistent 
list that need to be cleared, so the first reflex is not to think about 
slicing.  They end up in a situation where they only use slicing to 
clear the lists they use, when their problem has nothing to do with 
slicing IMHO.

But I understand that would add yet another way to clear a list, while 
the function is necessary for sets and dictionaries.

Regards,
Nicolas


From python at rcn.com  Fri Jul  1 01:33:11 2005
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 30 Jun 2005 19:33:11 -0400
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API for
	sets.Set and build-in set)
In-Reply-To: <da1u8v$9nf$1@sea.gmane.org>
Message-ID: <001b01c57dcc$14a22c20$1330cb97@oemcomputer>

> Raymond Hettinger wrote:
> > Use copy.copy() for generic copying -- it works across a wide range
of
> > objects.  Alternatively, use the constructor as generic way to make
> > duplicates:
> >
> >    dup = set(s)
> >    dup = list(l)
> >    dup = dict(d)
> >    dup = tuple(t)     # note, the duplicate is original object here
:-)

[Nicolas Fleury]
> I know all this, but why then is there a copy method for sets and
> dictionaries?  What justification is valid for sets and dictionaries
> that doesn't apply to lists?

Several thoughts:

* maybe it's a Dutch thing;

* dict.copy() pre-dated dict(d) and (IIRC) copy.copy();

* sets and dicts don't have the [:] syntax available to them;

* the __copy__() method is new way to make things copy.copyable
  without fattening the apparent API or rewriting the copy module;

* because generic copying isn't important enough to add more 
  ways to do the same thing;

* and because Guido believes beginners tend to copy too much
  (that is one reason why copy.copy is not a builtin) and that
  the language should encourage correct behavior.


Raymond

From nyamatongwe at gmail.com  Fri Jul  1 01:46:59 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Fri, 1 Jul 2005 09:46:59 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <ca471dc20506272343cbe7614@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<5.1.1.6.0.20050626133610.03652688@mail.telecommunity.com>
	<Pine.LNX.4.62.0506262014050.18093@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050626204633.02102cc8@mail.telecommunity.com>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
Message-ID: <50862ebd05063016466f3e6abd@mail.gmail.com>

Guido van Rossum:

> Whoa! Do we really need a completely different mechanism for doing the
> same stuff we can already do? 

   One benefit I see for the path module is that it makes it easier to
write code that behaves correctly with unicode paths on Windows.
Currently, to implement code that may see unicode paths, you must
first understand that unicode paths may be an issue, then write
conditional code that uses either a string or unicode string to hold
paths whenever a new path is created.

   Neil

From dlyzxl at yahoo.com  Fri Jul  1 04:35:47 2005
From: dlyzxl at yahoo.com (Justin)
Date: Thu, 30 Jun 2005 19:35:47 -0700 (PDT)
Subject: [Python-Dev] how to create single exe dos file
Message-ID: <20050701023547.57150.qmail@web51105.mail.yahoo.com>

Hi All:
 
I have a bundle of python script files (developed based on 2.*) in one application. Is there a way to create a single Dos executable file?
 
thanks,
 
Justin



		
---------------------------------
Yahoo! Mail Mobile
 Take Yahoo! Mail with you! Check email on your mobile phone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20050630/0d53743d/attachment-0001.htm

From dlyzxl at yahoo.com  Fri Jul  1 05:27:41 2005
From: dlyzxl at yahoo.com (Justin)
Date: Thu, 30 Jun 2005 20:27:41 -0700 (PDT)
Subject: [Python-Dev] cephes module missing
Message-ID: <20050701032742.67520.qmail@web51105.mail.yahoo.com>

When I used py2exe to create executable file, "cephes" module missing error occurred.
 
I have installed python 2.3 and scientific and numeric python. 
 
Can anybody suggest me how to resolve the problem?
 
thanks,
 
Justin



		
---------------------------------
Yahoo! Sports
 Rekindle the Rivalries. Sign up for Fantasy Football
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20050630/538b6440/attachment.htm

From tdelaney at avaya.com  Fri Jul  1 05:29:47 2005
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Fri, 1 Jul 2005 13:29:47 +1000
Subject: [Python-Dev] cephes module missing
Message-ID: <2773CAC687FD5F4689F526998C7E4E5F05CB11@au3010avexu1.global.avaya.com>

Justin wrote:

> When I used py2exe to create executable file, "cephes" module missing
> error occurred. 
> 
> I have installed python 2.3 and scientific and numeric python.
> 
> Can anybody suggest me how to resolve the problem?

python-dev is for development *of* python, not *with* python. Please
direct your questions to <python-list at python.org> (or via the newsgroup
comp.lang.python).

Tim Delaney

From esrever_otua at pythonhacker.is-a-geek.net  Fri Jul  1 06:29:34 2005
From: esrever_otua at pythonhacker.is-a-geek.net (Darryl Dixon)
Date: Fri, 01 Jul 2005 16:29:34 +1200
Subject: [Python-Dev] getch() in msvcrt does not accept extended characters.
Message-ID: <1120192174.9535.4.camel@unixadmindazfc2.chh.co.nz>

Hi,

    I'm sorry, I don't seem to have done a very good job at explaining
the situation.  I'll try again:
'getch()' is a low-level function provided on Windows to capture a
single character of input from a user, /without echoing it to the
screen/.  As far as I can tell there's no other way of doing this with
Python on Windows.  The Python interface to this function is in the C
code in msvcrtmodule.c, which has a (very thin) wrapper around the raw
OS system call.  Microsoft provide a way of accepting both normal ASCII
codes, and extended characters via this system call.  Currently, the
Python wrapper in msvcrtmodule.c only supports the semantics of getting
the bare ASCII codes, and not the extended characters.  I would strongly
suggest that it should support both.

So, I guess in answer to the questions raised below;

1) I can't do it in Python code without getch() (hence the original
email)

2) I would argue that in fact getch() is 'broken' in its current Python
implementation, as it doesn't support what the OS implies /should/ be
supported (and, indeed, if I input an extended character in response to
a 'getch()' call, all I get back currently is an empty string).

Finally, I've dug a little deeper, and it looks as though if (ch >
UCHAR_MAX) then it would have to call PyUnicode_FromUnicode(s, 1)
instead.

Is it worth sending in a patch to the sourceforge patch-tracker
implementing this?  Is it OK for msvcrt_getch to return Unicode when
appropriate?

Thoughts?

Hope this helps,
D


Fredrik wrote:
>Darryl Dixon wrote:
>
>> Microsoft support capturing extended characters via _getch, but it
requires making a
>> second call to getch() if one of the 'magic' returns is encountered
in the first call (0x00
>> or 0xE0).
>
>so why not do that in your python code?
>
>> The relevant chunk of code in Python that would probably need to be
>> changed to support this appears to be in msvcrtmodule.c:
>
>if you change msvcrt, you'll break all the programs that uses getch()
in
>the prescribed way...
>
></F> 
-- 
Darryl Dixon <esrever_otua at pythonhacker.is-a-geek.net>


From theller at python.net  Fri Jul  1 08:45:14 2005
From: theller at python.net (Thomas Heller)
Date: Fri, 01 Jul 2005 08:45:14 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
References: <d9mmd6$gjf$1@sea.gmane.org>
	<5.1.1.6.0.20050626133610.03652688@mail.telecommunity.com>
	<Pine.LNX.4.62.0506262014050.18093@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050626204633.02102cc8@mail.telecommunity.com>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
Message-ID: <r7ej9g91.fsf@python.net>

> Guido van Rossum:
>
>> Whoa! Do we really need a completely different mechanism for doing the
>> same stuff we can already do? 
>

Neil Hodgson <nyamatongwe at gmail.com> writes:

>    One benefit I see for the path module is that it makes it easier to
> write code that behaves correctly with unicode paths on Windows.
> Currently, to implement code that may see unicode paths, you must
> first understand that unicode paths may be an issue, then write
> conditional code that uses either a string or unicode string to hold
> paths whenever a new path is created.

Indeed.  This would probably handle the cases where you have to
manipulate file paths in code.

OTOH, Python is lacking a lot when you have to handle unicode strings on
sys.path, in command line arguments, environment variables and maybe
other places.  See, for example
http://mail.python.org/pipermail/python-list/2004-December/256969.html

I had started to work on the sys.path unicode issues, but it seems a
considerable rewrite of (not only) Python/import.c is required.  But I
fear the patch http://python.org/sf/1093253 is slowly getting out of
date.

Thomas


From eric.nieuwland at xs4all.nl  Fri Jul  1 10:43:15 2005
From: eric.nieuwland at xs4all.nl (Eric Nieuwland)
Date: Fri, 1 Jul 2005 10:43:15 +0200
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
References: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
Message-ID: <cf08433f4ea325e1b7ae2368df3df375@xs4all.nl>

Raymond Hettinger wrote:

> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
>
> What term should describe those objects in the documentation?

Witty objects?


From ncoghlan at gmail.com  Fri Jul  1 11:59:07 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 01 Jul 2005 19:59:07 +1000
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
References: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
Message-ID: <42C513EB.6030607@gmail.com>

Raymond Hettinger wrote:
> Whatever term is selected, it should be well thought-out and added to
> the glossary.  The choice of words will likely have a great effect on
> learnability and on how people think about the new tool.

When writing PEP 346, I ended up choosing "user defined statement" as 
a generic term for the sundry ways that the 'with' statement could be 
used. Signal blocking, exception logging, transactions, resource 
management, etc. . .

For me, the key point was that to understand what a 'with' statement 
is really doing, you needed to understand the behaviour of the 
supplied object. This is far less the case with other compound Python 
statements.

For 'if' statements and 'while' loops, the supplied object will always 
be interpreted as a boolean. In 'for' loops, the supplied object is 
guaranteed to return a series of other objects. An 'except' clause 
always expects an exception type of some description.

For 'with' statements, all we really know is that the object may do 
something before the suite it is entered, and something else as the 
suite is exited. Other than that, it could be (or do) anything. Hence, 
'user defined statement'.

With that piece of terminology in place, the natural outcome was to 
call objects that supplied __enter__ and __exit__ methods "statement 
templates".

I also used this term to come up with PEP 346's name for the generator 
to statement template conversion decorator: "stmt_template"

(Like others, the fact that 'with' is a verb makes it very hard for me 
to interpret "with_template" correctly when I see it as a decorator - 
I always want to ask "with which template?")

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From facundobatista at gmail.com  Fri Jul  1 13:58:52 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 1 Jul 2005 08:58:52 -0300
Subject: [Python-Dev] Decimal rounding doc
Message-ID: <e04bdf31050701045839153a51@mail.gmail.com>

I'm preparing the pre-PEP of a Money module, and I don't want to
explain the rounding methods there again.

So my idea was to point to Decimal documentation regarding them. And I
couldn't find them.

Could it be we missed the explanation of each rounding mode in the
Decimal docs? Or the sprints burned my head?

If somebody confirm me that they're not explained, I'll open a bug to
myself to do it...

Thanks. 

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From ncoghlan at gmail.com  Fri Jul  1 14:46:38 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 01 Jul 2005 22:46:38 +1000
Subject: [Python-Dev] Decimal rounding doc
In-Reply-To: <e04bdf31050701045839153a51@mail.gmail.com>
References: <e04bdf31050701045839153a51@mail.gmail.com>
Message-ID: <42C53B2E.3060804@gmail.com>

Facundo Batista wrote:
> I'm preparing the pre-PEP of a Money module, and I don't want to
> explain the rounding methods there again.
> 
> So my idea was to point to Decimal documentation regarding them. And I
> couldn't find them.
> 
> Could it be we missed the explanation of each rounding mode in the
> Decimal docs? Or the sprints burned my head?
> 
> If somebody confirm me that they're not explained, I'll open a bug to
> myself to do it...

The best I found was this bit in the documentation of the 'Context' 
constructor:

"The rounding option is one of: ROUND_CEILING (towards Infinity), 
ROUND_DOWN (towards zero), ROUND_FLOOR (towards -Infinity), 
ROUND_HALF_DOWN (towards zero), ROUND_HALF_EVEN, ROUND_HALF_UP (away 
from zero), or ROUND_UP (away from zero)."

Something a bit more forthcoming probably wouldn't hurt - 
specifically, explaining the reasoning behind 'ROUND_HALF_EVEN' would 
be good.

Maybe you could put some headings on the 'Floating point notes' page 
and include an explanation of the rounding modes with the two existing 
discussions on that page:
  - Rounding Errors and Precision (existing)
  - Rounding Modes (new)
  - Special Floating Point Values (existing)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From aahz at pythoncraft.com  Fri Jul  1 14:48:14 2005
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 1 Jul 2005 05:48:14 -0700
Subject: [Python-Dev] getch() in msvcrt does not accept extended
	characters.
In-Reply-To: <1120192174.9535.4.camel@unixadmindazfc2.chh.co.nz>
References: <1120192174.9535.4.camel@unixadmindazfc2.chh.co.nz>
Message-ID: <20050701124814.GC6964@panix.com>

On Fri, Jul 01, 2005, Darryl Dixon wrote:
>
> Is it worth sending in a patch to the sourceforge patch-tracker
> implementing this?  Is it OK for msvcrt_getch to return Unicode when
> appropriate?

Let's put it this way: you probably won't get much in the way of forward
motion on this unless you do post a patch.  It passes the smell test of
not being horribly unPythonic, if that's what you want to know.  Note
that you're likely to be required to add a new function with this
feature, but that can be argued later.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From aahz at pythoncraft.com  Fri Jul  1 14:50:41 2005
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 1 Jul 2005 05:50:41 -0700
Subject: [Python-Dev] Decimal rounding doc
In-Reply-To: <e04bdf31050701045839153a51@mail.gmail.com>
References: <e04bdf31050701045839153a51@mail.gmail.com>
Message-ID: <20050701125040.GD6964@panix.com>

On Fri, Jul 01, 2005, Facundo Batista wrote:
>
> I'm preparing the pre-PEP of a Money module, and I don't want to
> explain the rounding methods there again.
> 
> So my idea was to point to Decimal documentation regarding them. And I
> couldn't find them.
> 
> Could it be we missed the explanation of each rounding mode in the
> Decimal docs? Or the sprints burned my head?

My suspicion is that someone at some point thought that Cowlishaw was
sufficient; we probably should write some base-level docs that explain
the Python mechanisms and refer to Cowlishaw for details.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From facundobatista at gmail.com  Fri Jul  1 14:55:46 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 1 Jul 2005 09:55:46 -0300
Subject: [Python-Dev] Decimal rounding doc
In-Reply-To: <20050701125040.GD6964@panix.com>
References: <e04bdf31050701045839153a51@mail.gmail.com>
	<20050701125040.GD6964@panix.com>
Message-ID: <e04bdf31050701055559214150@mail.gmail.com>

On 7/1/05, Aahz <aahz at pythoncraft.com> wrote:

> My suspicion is that someone at some point thought that Cowlishaw was
> sufficient; we probably should write some base-level docs that explain
> the Python mechanisms and refer to Cowlishaw for details.

Well, it's already well explained, with examples and all, in the PEP 327:

http://www.python.org/peps/pep-0327.html#rounding-algorithms

I'll point to there from the Money PEP, but I think this should be
somewhere in the docs. I mean, as a final user, you shouldn't read a
PEP or a 3rd party doc to know how to use a module.

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From tjreedy at udel.edu  Fri Jul  1 15:11:55 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 1 Jul 2005 09:11:55 -0400
Subject: [Python-Dev] getch() in msvcrt does not accept extended
	characters.
References: <1120192174.9535.4.camel@unixadmindazfc2.chh.co.nz>
Message-ID: <da3f0h$ref$1@sea.gmane.org>


"Darryl Dixon" <esrever_otua at pythonhacker.is-a-geek.net> wrote in message 
news:1120192174.9535.4.camel at unixadmindazfc2.chh.co.nz...
> Python on Windows.  The Python interface to this function is in the C
> code in msvcrtmodule.c, which has a (very thin) wrapper around the raw
> OS system call.

I think Fredrik made two points in this regard.  1) The current 
thin-wrapperness is intentional, not a bug.  2) Changing the behavior would 
break programs that depend on this feature.  Not good.

So, as Aahz also suggested, I suspect a new function might have more 
chance.

Terry J. Reedy




From mark.russell at redmoon.me.uk  Fri Jul  1 16:54:06 2005
From: mark.russell at redmoon.me.uk (Mark Russell)
Date: Fri, 01 Jul 2005 15:54:06 +0100
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
References: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
Message-ID: <1120229646.5848.8.camel@localhost>

On Thu, 2005-06-30 at 22:41, Raymond Hettinger wrote:
> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
> 
> What term should describe those objects in the documentation?  

Their raison d'etre is to bracket user code with setup and teardown
methods, so how about the term "bracketing object"?

Mark Russell




From python at rcn.com  Fri Jul  1 17:36:14 2005
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 1 Jul 2005 11:36:14 -0400
Subject: [Python-Dev] Decimal rounding doc
In-Reply-To: <e04bdf31050701055559214150@mail.gmail.com>
Message-ID: <002001c57e52$9e14aba0$aa36c797@oemcomputer>

> http://www.python.org/peps/pep-0327.html#rounding-algorithms
> 
> I'll point to there from the Money PEP, but I think this should be
> somewhere in the docs. I mean, as a final user, you shouldn't read a
> PEP or a 3rd party doc to know how to use a module.

I've got it from here.  Will update the docs.


Raymond

From pje at telecommunity.com  Fri Jul  1 17:44:16 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 01 Jul 2005 11:44:16 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
Message-ID: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>

At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote:
>With 343 accepted, we can now add __enter__() and __exit__() methods to
>objects.
>
>What term should describe those objects in the documentation?

Resource managers.


From fdrake at acm.org  Fri Jul  1 17:43:10 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 1 Jul 2005 11:43:10 -0400
Subject: [Python-Dev] Decimal rounding doc
In-Reply-To: <e04bdf31050701055559214150@mail.gmail.com>
References: <e04bdf31050701045839153a51@mail.gmail.com>
	<20050701125040.GD6964@panix.com>
	<e04bdf31050701055559214150@mail.gmail.com>
Message-ID: <200507011143.10388.fdrake@acm.org>

On Friday 01 July 2005 08:55, Facundo Batista wrote:
 > I'll point to there from the Money PEP, but I think this should be
 > somewhere in the docs. I mean, as a final user, you shouldn't read a
 > PEP or a 3rd party doc to know how to use a module.

Please file a documentation bug on SF, with this link to the specific PEP 
section, so that we can get this fixed.

Unless, of course, you have the time and inclination to finish it off 
yourself.  :-)

(I know, I've not been very helpful getting doc issues cleared up lately; I'm 
hoping that'll get a bit better soon.)


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From aahz at pythoncraft.com  Fri Jul  1 17:43:57 2005
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 1 Jul 2005 08:43:57 -0700
Subject: [Python-Dev] Missing docs (was Decimal rounding doc)
In-Reply-To: <e04bdf31050701055559214150@mail.gmail.com>
References: <e04bdf31050701045839153a51@mail.gmail.com>
	<20050701125040.GD6964@panix.com>
	<e04bdf31050701055559214150@mail.gmail.com>
Message-ID: <20050701154357.GA1345@panix.com>

On Fri, Jul 01, 2005, Facundo Batista wrote:
> On 7/1/05, Aahz <aahz at pythoncraft.com> wrote:
>> 
>> My suspicion is that someone at some point thought that Cowlishaw was
>> sufficient; we probably should write some base-level docs that explain
>> the Python mechanisms and refer to Cowlishaw for details.
> 
> Well, it's already well explained, with examples and all, in the PEP 327:
> 
> http://www.python.org/peps/pep-0327.html#rounding-algorithms
> 
> I'll point to there from the Money PEP, but I think this should be
> somewhere in the docs. I mean, as a final user, you shouldn't read a
> PEP or a 3rd party doc to know how to use a module.

Agreed.  Unfortunately, that's one big area where Python needs work;
new-style classes are probably the worst.  If you wanted to take the
lead and push a sprint on doc work, you'd be a hero.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From fdrake at acm.org  Fri Jul  1 17:44:11 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 1 Jul 2005 11:44:11 -0400
Subject: [Python-Dev] Decimal rounding doc
In-Reply-To: <002001c57e52$9e14aba0$aa36c797@oemcomputer>
References: <002001c57e52$9e14aba0$aa36c797@oemcomputer>
Message-ID: <200507011144.11508.fdrake@acm.org>

On Friday 01 July 2005 11:36, Raymond Hettinger wrote:
 > I've got it from here.  Will update the docs.

Dang, a race condition.  :-)

Ok, Facundo, never mind the SF tracker item.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From fdrake at acm.org  Fri Jul  1 17:45:22 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 1 Jul 2005 11:45:22 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
References: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
Message-ID: <200507011145.22960.fdrake@acm.org>

On Friday 01 July 2005 11:44, Phillip J. Eby wrote:
 > Resource managers.

Yeah, I was thinking that, but was somewhat ambivalent.  But I definately like 
it better than anything else proposed so far.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From facundobatista at gmail.com  Fri Jul  1 17:51:54 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 1 Jul 2005 12:51:54 -0300
Subject: [Python-Dev] Decimal rounding doc
In-Reply-To: <200507011144.11508.fdrake@acm.org>
References: <002001c57e52$9e14aba0$aa36c797@oemcomputer>
	<200507011144.11508.fdrake@acm.org>
Message-ID: <e04bdf310507010851756bcd5b@mail.gmail.com>

On 7/1/05, Fred L. Drake, Jr. <fdrake at acm.org> wrote:

> On Friday 01 July 2005 11:36, Raymond Hettinger wrote:
>  > I've got it from here.  Will update the docs.
> 
> Dang, a race condition.  :-)
> 
> Ok, Facundo, never mind the SF tracker item.

:p.

My original idea was to ask you for another pair of eyes, and I'd
solve it myself.

But, well, the sprint day here is finishing and I still didn't ended
the Money test cases, so Raymond, go ahead if you like... and thanks!

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From facundobatista at gmail.com  Fri Jul  1 18:16:09 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 1 Jul 2005 13:16:09 -0300
Subject: [Python-Dev] Missing docs (was Decimal rounding doc)
In-Reply-To: <20050701154357.GA1345@panix.com>
References: <e04bdf31050701045839153a51@mail.gmail.com>
	<20050701125040.GD6964@panix.com>
	<e04bdf31050701055559214150@mail.gmail.com>
	<20050701154357.GA1345@panix.com>
Message-ID: <e04bdf310507010916544c4c3b@mail.gmail.com>

On 7/1/05, Aahz <aahz at pythoncraft.com> wrote:

> Agreed.  Unfortunately, that's one big area where Python needs work;
> new-style classes are probably the worst.  If you wanted to take the
> lead and push a sprint on doc work, you'd be a hero.

Ehhh... what a good idea for PyCon 2006!!

:D

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From facundobatista at gmail.com  Fri Jul  1 18:43:07 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 1 Jul 2005 13:43:07 -0300
Subject: [Python-Dev] Money module
Message-ID: <e04bdf31050701094357ea5f84@mail.gmail.com>

People:

The Money two-days sprint in EuroPython 2005 has finished.

We advanced a lot. The pre-PEP is almost done, and the corresponding
test cases are all written.

We need to finish the structure procesing for currency general
information, and bring general functions to the module, but most of
the decision-taking part is done.

So, it's not a chaos any more, it's in a very coherent state, but yet
it's not everything written in stone. So, if you want to influence
somehow in the Money module, this is the moment to get in and
participate.

The project is in SourceForge
(http://sourceforge.net/projects/pymoney), and there we have a mailing
list (just to not bloat this one).

Thank you.

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From bcannon at gmail.com  Fri Jul  1 18:48:45 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Fri, 1 Jul 2005 09:48:45 -0700
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <200507011145.22960.fdrake@acm.org>
References: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
	<200507011145.22960.fdrake@acm.org>
Message-ID: <bbaeab1005070109487db8b60c@mail.gmail.com>

On 7/1/05, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
> On Friday 01 July 2005 11:44, Phillip J. Eby wrote:
>  > Resource managers.
> 
> Yeah, I was thinking that, but was somewhat ambivalent.  But I definately like
> it better than anything else proposed so far.
> 

I say we steal from the C++ and the RAII paradigm and go with RMUW
(Resource Management Using 'with').  No need to get cutesy and we
already have acronym overload anyway, so one more won't kill us.

-Brett

From barry at python.org  Fri Jul  1 18:58:54 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 01 Jul 2005 12:58:54 -0400
Subject: [Python-Dev] Inconsistent API for sets.Set and build-in set
In-Reply-To: <001601c57d9a$52ae08e0$1721a044@oemcomputer>
References: <001601c57d9a$52ae08e0$1721a044@oemcomputer>
Message-ID: <1120237133.9792.35.camel@geddy.wooz.org>

On Thu, 2005-06-30 at 13:37, Raymond Hettinger wrote: 
> > If there are no objections, I propose to do the following (only in
> > Python 2.4 and 2.5):
> > 
> >       * Add set.union_update() as an alias for set.update().
> 
> No.  It was intentional to drop the duplicate method with the
> hard-to-use name.  There was some thought given to deprecating
> sets.union_update() but that would have just caused unnecessary grief.

Oh, okay.  Did you run out of clever abbreviations after
s/union_update/update/ or do you think that symmetric_difference_update
is already easy enough to use? ;)

Why was "update" chosen when you have two other forms of longer
*_update() methods on sets?  This is after all, a union and it's
arguably more confusing not to have that in the name (especially given
the "easy-to-use" other *_update() methods).

> > I consider this a bug in 2.4, not a new feature, because without it,
> it
> > makes more work in porting applications.
> 
> Bah.  It's just one of the handful of search/replace steps:
> 
>    Set --> set
>    ImmutableSet --> frozenset
>    union_update --> update

But an unnecessary one, IMO.

> > I'm willing to Just Fix It,
> 
> Please don't.  All of the differences between set and Set were
> intentional improvements (i.e. the hash algorithm's are different).

I don't care about the implementation, I'm sure it's vastly superior.
I'm concerned with the API.  I don't agree that dropping union_update()
is necessarily an improvement, but I guess I had my chance when the PEP
was being debated, so I'll drop it.

I do think you owe it to users to describe the differences in PLR $2.3.7
to aid people in the transition process.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050701/bac40886/attachment.pgp

From python at rcn.com  Fri Jul  1 20:12:34 2005
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 1 Jul 2005 14:12:34 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <bbaeab1005070109487db8b60c@mail.gmail.com>
Message-ID: <000e01c57e68$74ce41a0$aa36c797@oemcomputer>

[Brett Cannon]
> I say we steal from the C++ and the RAII paradigm and go with RMUW
> (Resource Management Using 'with'

Or the-keyword-formerly-known-as-do


Raymond

From python at rcn.com  Fri Jul  1 20:55:55 2005
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 1 Jul 2005 14:55:55 -0400
Subject: [Python-Dev] Money module
In-Reply-To: <e04bdf31050701094357ea5f84@mail.gmail.com>
Message-ID: <001201c57e6e$83056b80$aa36c797@oemcomputer>

[Facundo]
> The pre-PEP is almost done, and the corresponding
> test cases are all written.

What is the part about the pre-PEP?  Something like this probably
shouldn't go in the standard library until it has been proven in the
field.  This doubly true for a module that has made some unusual OO
design choices and has an unconventional decomposition of financial
functions.  

* The exchange rate mechanism may end-up not being workable as it does
not incorporate rate changes over time, differing forward and reverse
rates, non-linear factors such as commission/fees, source currency, or
multiple suppliers.

* Time value of money computations are typically dimensionless (not
sensitive to currency type or formatting) and they often have algorithm
specific rounding needs (round at the end of compounding period or each
year or only at the end).

* The absence of a division operator may prove problematic for
allocation routines.

* Usually numeric formatting is kept independent from the rest of the
design.  It will be interesting to see how workable it is to make it
part of the Context object.  In Excel for instance, formatting is a
property of some part of the hierarchy of worksheet, row or column, or
specific cell.  It is not linked to the context for mathematical
operations.

While the Money module remains experimental, it should remain a
third-party package.



Raymond

From rrr at ronadam.com  Fri Jul  1 21:53:43 2005
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 01 Jul 2005 15:53:43 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <42C513EB.6030607@gmail.com>
References: <000d01c57dbc$71df2420$1330cb97@oemcomputer>
	<42C513EB.6030607@gmail.com>
Message-ID: <42C59F47.7070305@ronadam.com>

Nick Coghlan wrote:
> Raymond Hettinger wrote:
> 
>>Whatever term is selected, it should be well thought-out and added to
>>the glossary.  The choice of words will likely have a great effect on
>>learnability and on how people think about the new tool.

I tried to bring this up on python-list, but I didn't get much of a 
response.  I suggested "witherator" as a too cute alternative, but was 
hoping to get some alternatives to that.

   http://mail.python.org/pipermail/python-list/2005-June/286684.html

> For 'with' statements, all we really know is that the object may do 
> something before the suite it is entered, and something else as the 
> suite is exited. Other than that, it could be (or do) anything. Hence, 
> 'user defined statement'.

I would say the key attribute is the "and something else as the suite is 
exited" part.  With out that, the "with" statement isn't needed and a 
regular function or generator would work.

A term which stresses finalizing may be appropriate.


> With that piece of terminology in place, the natural outcome was to 
> call objects that supplied __enter__ and __exit__ methods "statement 
> templates".

Will objects be created that can be used with and without "with" 
statements?  I think that this could be a source of confusion.

It seems to me that "with" statements require a "with" object, and that 
those objects probably shouldn't be used without the "with" statement. 
Having a clear separation might be a good idea.

Should there be a "with" (different name most likely) type?

Would there be any advantages of a "with" base object that can have 
constructor methods that can accept either a try-finally generator or 
two functions to insert into the __enter__ and __exit__ methods as 
arguments?

For example, call a with object a "manage" object then:

    with manage.generator(open_file_gen) as f:
        BLOCK

    with manage.enter_exit(lock_func, unlock_func) as lock:
        BLOCK



> I also used this term to come up with PEP 346's name for the generator 
> to statement template conversion decorator: "stmt_template"
 >
> (Like others, the fact that 'with' is a verb makes it very hard for me 
> to interpret "with_template" correctly when I see it as a decorator - 
> I always want to ask "with which template?")

I agree, the decorator adds a layer of complexity to it. I think the 
with-generator behavior needs to be described without the decorator 
version first, then the decorator becomes syntactic sugar to make it 
easier to do the same thing.

Ron


From nidoizo at yahoo.com  Fri Jul  1 22:04:58 2005
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Fri, 01 Jul 2005 16:04:58 -0400
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API for
 sets.Set and build-in set)
In-Reply-To: <001b01c57dcc$14a22c20$1330cb97@oemcomputer>
References: <da1u8v$9nf$1@sea.gmane.org>
	<001b01c57dcc$14a22c20$1330cb97@oemcomputer>
Message-ID: <da4712$79c$1@sea.gmane.org>

Raymond Hettinger wrote:
> Several thoughts:

As I told you in a private dicussion, you have convinced me about copy. 
  About clear, however, I feel I have to defend my colleagues and 
myself, who almost all wasted time once (but only once) searching how to 
clear a list.  Improving the docs (like adding an additional example in 
the table at http://www.python.org/doc/2.4.1/lib/typesseq-mutable.html) 
would be good.  To me, "del mylist[:]" and "mylist[:] = []" are not "how 
to clear a list" but "how to clear list using slicing".  That's why I 
think it's counter-intuitive, since you end up using slicing in a 
situation that has nothing to do with slicing.

We agree there's no need about generic clearing.  It's only about 
consistency and ease of learning/self-documentation.  So let's look at 
the reasons to not do it:

- It's only useful for new Python programmers (I mean first-time 
clearers), once you know it, you know it.
- That would be a third way to clear a list.  However, I don't like this 
argument in this specific case, because IMO the current ways are just 
slicing capabilities, as "<< 1" and "* 2" can be the same on a int.
- All APIs trying to emulate a list would end up incomplete.  I have 
difficulty judging that one.  A method addition doesn't sound so bad to 
me.  If it is the showstopper, maybe a Python 3000 thing?

Overall, I think the addition of clear would be an improvement to the 
language, particularly in the autocompletion world of ours;)

Regards,
Nicolas


From python at rcn.com  Fri Jul  1 23:49:11 2005
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 1 Jul 2005 17:49:11 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <42C59F47.7070305@ronadam.com>
Message-ID: <002e01c57e86$b7915680$aa36c797@oemcomputer>

 [Raymond]
> >>Whatever term is selected, it should be well thought-out and added
to
> >>the glossary.  The choice of words will likely have a great effect
on
> >>learnability and on how people think about the new tool.

[Ron Adam]
> I tried to bring this up on python-list, but I didn't get much of a
> response.  I suggested "witherator" as a too cute alternative, but was
> hoping to get some alternatives to that.

That wins in the cuteness and trademarkability categories ;-)

Here is a more plain and direct alternative proposal:

  "Decimal objects support the enter/exit protocol"



On a separate note, I also propose that __exit__() be renamed to
__leave__().  The enter/leave word pairing are a better fit in standard
English:

  Entering the Austin city limits ... Leaving the Austin city limits.
  You may enter ... You may leave.
  Enter the Dragon ... Elvis has left the building.

FWIW, there is precedent in x86 assembly language:

  enter:  sets up nested procedure definition
  leave:  reverses the effect of enter

Likewise, GUI programmers use Enter and Leave for mouse events.

Google has no shortage of hits for the pairing:

   http://www.google.com/search?q="enter+or+leave"



Raymond

From mcherm at mcherm.com  Sat Jul  2 00:23:30 2005
From: mcherm at mcherm.com (Michael Chermside)
Date: Fri, 01 Jul 2005 15:23:30 -0700
Subject: [Python-Dev] Terminology for PEP 343
Message-ID: <20050701152330.e8s0c33fogg88kws@login.werra.lunarpages.com>

Raymond writes:
> On a separate note, I also propose that __exit__() be renamed to
> __leave__(). The enter/leave word pairing are a better fit in standard
> English:


I don't feel strongly about it, but I tend to disagree. Certainly you
will admit that enter-exit IS a gramatically correct pairing in
English.

Raymond argues that:
> Google has no shortage of hits for the pairing:

Yes, but google has about half as many hits for the enter-exit pairing.
I think a factor of 2 is not really that big for this sort of thing.
I would take that to mean that enter-leave and enter-exit are roughly
equally frequent pairs with enter-leave being somewhat more prevelant.

> FWIW, there is precedent in x86 assembly language:
> Likewise, GUI programmers use Enter and Leave for mouse events.

These precedents stand. I don't find them compelling, but they
are certainly valid.

In favor of "exit" over "leave" I have only two arguments. First, I
just like "exit" better. Hmm... didn't find that compelling? I was
afraid of that.

The second (also not a very strong argument) is that "exit" is somewhat
more distinct in meaning than "leave". Somehow for me "exit" has a
faint connotation of a distinct boundary being crossed, while "leave"
is somewhat less crisp.

I would use "She left the ballpark." for someone walking into the
dugout, climbing up into the stands, or walking out of the stadium,
and might refer to the entire process. Using "She exited the ballpark."
to me suggests the exact moment that she went through the door
dividing outside from inside. If you accept this connotation, then
it's clear that "exit" is a closer match for the with statement's
behavior than "leave".

Anyway, this stuff is always very subjective and, as I said, I'm just
expressing an opinion. So take it for what it's worth.

-- Michael Chermside


From python at rcn.com  Sat Jul  2 00:52:15 2005
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 1 Jul 2005 18:52:15 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <20050701152330.e8s0c33fogg88kws@login.werra.lunarpages.com>
Message-ID: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>

> I would use "She left the ballpark." for someone walking into the
> dugout, climbing up into the stands, or walking out of the stadium,
> and might refer to the entire process. Using "She exited the
ballpark."
> to me suggests the exact moment that she went through the door
> dividing outside from inside. If you accept this connotation, then
> it's clear that "exit" is a closer match for the with statement's
> behavior than "leave".
> 
> Anyway, this stuff is always very subjective and, as I said, I'm just
> expressing an opinion. So take it for what it's worth.

Hmm, that got me to thinking a bit more.  Here's another subjective two
cents worth.  "exit" seems to be a more global concept and "leave" seems
more local.  For instance, I leave a room but exit a building.  In
Python, sys.exit and os._exit are grand exits rather than local exits
for functions or modules.


Raymond

From rwgk at cci.lbl.gov  Sat Jul  2 00:59:46 2005
From: rwgk at cci.lbl.gov (Ralf W. Grosse-Kunstleve)
Date: Fri, 1 Jul 2005 15:59:46 -0700 (PDT)
Subject: [Python-Dev] reducing self.x=x; self.y=y; self.z=z boilerplate code
Message-ID: <200507012259.j61MxkBv308450@boa.lbl.gov>

Hi,

I often find myself writing:

  class grouping:

      def __init__(self, x, y, z):
          self.x = x
          self.y = y
          self.z = z

I hate it, and every time I show this to a Python newcomer I get that
skeptic look. How about this for a change?

  class grouping:

      def __init__(self, .x, .y, .z):
          pass

This is supposed to work the same way as:

      def __init__(self, x, y, z):
          self.x = x
          del x
          self.y = y
          del y
          self.z = z
          del z

Currently the .x syntax leads to:

      def __init__(self, .x, .y, .z):
                         ^
  SyntaxError: invalid syntax

I.e. it seems to me that there shouldn't be any backward compatibility
issues.

I'll write a PEP if I hear a few voices of support.
(Otherwise I'll stick to my "adopt_init_args" workaround:
http://phenix-online.org/cctbx_sources/libtbx/libtbx/introspection.py
which does a similar job but doesn't look as elegant and is also
quite inefficient).

Cheers,
        Ralf

From pje at telecommunity.com  Sat Jul  2 01:22:20 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 01 Jul 2005 19:22:20 -0400
Subject: [Python-Dev] reducing self.x=x; self.y=y;
 self.z=z  boilerplate code
In-Reply-To: <200507012259.j61MxkBv308450@boa.lbl.gov>
Message-ID: <5.1.1.6.0.20050701191254.02719210@mail.telecommunity.com>

At 03:59 PM 7/1/2005 -0700, Ralf W. Grosse-Kunstleve wrote:
>Hi,
>
>I often find myself writing:
>
>   class grouping:
>
>       def __init__(self, x, y, z):
>           self.x = x
>           self.y = y
>           self.z = z
>
>I hate it, and every time I show this to a Python newcomer I get that
>skeptic look. How about this for a change?
>
>   class grouping:
>
>       def __init__(self, .x, .y, .z):
>           pass

This extends to any number of arguments:

     class grouping:
         def __init__(self, x, y, z):
             self.__dict__.update(locals())
             del self.self

Or if you prefer a more generic approach:

     def initialize(ob, args):
         if 'self' in args:
             del args['self']
         for k, v in args.items():
             setattr(ob,k,v)


     class grouping:
         def __init__(self, x, y, z):
             initialize(self, locals())

There's really no need for special syntax here, if your goal is simply to 
reduce boilerplate.


>I'll write a PEP if I hear a few voices of support.

-1; there are lots of good solutions for this.  For me, I usually have a 
base class with something like this:

     def __init__(self, **kw):
         for k, v in kw.items():
             if not hasattr(self.__class__, k):
                 raise TypeError("%s has no %r attribute" % (self.__class__,k))
             else:
                 setattr(self,k,v)

And then subclasses define their attributes and defaults using class 
attributes, properties, or other descriptors.


>(Otherwise I'll stick to my "adopt_init_args" workaround:
>http://phenix-online.org/cctbx_sources/libtbx/libtbx/introspection.py
>which does a similar job but doesn't look as elegant and is also
>quite inefficient).

There are more efficient solutions, especially __dict__.update().


From exarkun at divmod.com  Sat Jul  2 01:28:31 2005
From: exarkun at divmod.com (Jp Calderone)
Date: Fri, 1 Jul 2005 19:28:31 -0400
Subject: [Python-Dev] reducing self.x=x; self.y=y;
 self.z=z  boilerplate code
In-Reply-To: <5.1.1.6.0.20050701191254.02719210@mail.telecommunity.com>
Message-ID: <20050701232831.26278.285122888.divmod.quotient.3955@ohm>

On Fri, 01 Jul 2005 19:22:20 -0400, "Phillip J. Eby" <pje at telecommunity.com> wrote:
>At 03:59 PM 7/1/2005 -0700, Ralf W. Grosse-Kunstleve wrote:
> [snip]
>
>This extends to any number of arguments:
>
>     class grouping:
>         def __init__(self, x, y, z):
>             self.__dict__.update(locals())
>             del self.self

If you use vars(self).update(locals()), it even looks halfway pleasant ;)  I'm not sure what python-dev's current opinion of vars(obj) is though (I'm hoping someone'll tell me).

Of course, both of these fall over for __slots__'ful classes.  It'd be nice if there were a general way to deal with attributes of an instance, regardless of the implementation details of its memory layout.

Jp

From rwgk at cci.lbl.gov  Sat Jul  2 01:59:49 2005
From: rwgk at cci.lbl.gov (Ralf W. Grosse-Kunstleve)
Date: Fri, 1 Jul 2005 16:59:49 -0700 (PDT)
Subject: [Python-Dev] reducing self.x=x; self.y=y;
	self.z=z boilerplate code
Message-ID: <200507012359.j61Nxn2F309246@boa.lbl.gov>

I am happy to see that others agree we need something better
than self.x=x; self.y=y; self.z=z.

Phillip J. Eby wrote:
>    class grouping:
>        def __init__(self, x, y, z):
>            initialize(self, locals())

Been there (older code):

  http://phenix-online.org/cctbx_sources/scitbx/scitbx/python_utils/misc.py

I don't like it because

  - I do have to remember how to import adopt_init_args/initialize.

  - I also have to remember the locals() part (unpythonic
    boilerplate again).

  - I get both self.x and x. This lead to subtle bugs a few times when
    I accidentally assigned to x instead of self.x or vice versa in the
    wrong place).

  - It is sure to be less efficient than the .x support I propose.

I'd be happy if

  - adopt_init_args/initialize became a (efficiently implemented)
    Python built-in.

  - and the locals() part is not needed.

However, IMO the .x solution is still far better because I often
want to do something like this:

  class grouping:

    def __init__(self, .keep_this, .and_this, but_not_this, .but_this_again):
      pass

With the adopt_init_args/initialize solution you'd have to write:

  class grouping:

    def __init__(self, keep_this, and_this, but_not_this, but_this_again):
      initialize(self, locals(), exclude=["but_not_this"])

Unpythonic boilerplate again (the but_not_this duplication).

Cheers,
        Ralf

From ncoghlan at gmail.com  Sat Jul  2 02:14:44 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 02 Jul 2005 10:14:44 +1000
Subject: [Python-Dev] reducing self.x=x; self.y=y;
 self.z=z  boilerplate code
In-Reply-To: <20050701232831.26278.285122888.divmod.quotient.3955@ohm>
References: <20050701232831.26278.285122888.divmod.quotient.3955@ohm>
Message-ID: <42C5DC74.1040904@gmail.com>

Jp Calderone wrote:
> If you use vars(self).update(locals()), it even looks halfway
> pleasant ;)  I'm not sure what python-dev's current opinion of
> vars(obj) is though (I'm hoping someone'll tell me).
> 
> Of course, both of these fall over for __slots__'ful classes.  It'd
> be nice if there were a general way to deal with attributes of an
> instance, regardless of the implementation details of its memory
> layout.

That's where PJE's more generic approach comes in:

      def initialize(ob, args, excluded=['self']):
          for k in excluded:
              if k in args:
                  del args[k]
          for k, v in args.items():
              setattr(ob,k,v)

      class grouping:
          def __init__(self, x, y, z):
              initialize(self, locals())


Or, one could have a look at the 'namespace' module, which came out of 
the last pre-PEP covering this kind of area:

http://namespace.python-hosting.com/

'Record' is particularly interesting from an auto-initialisation point 
of view (the class attributes define the expected instance 
attributes). Although I may be a little biased, since I wrote that 
class. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From ncoghlan at gmail.com  Sat Jul  2 02:28:41 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 02 Jul 2005 10:28:41 +1000
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <20050701152330.e8s0c33fogg88kws@login.werra.lunarpages.com>
References: <20050701152330.e8s0c33fogg88kws@login.werra.lunarpages.com>
Message-ID: <42C5DFB9.4050103@gmail.com>

Michael Chermside wrote:
> In favor of "exit" over "leave" I have only two arguments. First, I
> just like "exit" better. Hmm... didn't find that compelling? I was
> afraid of that.

I have a pretty simple reason for liking the enter/exit pair over the 
enter/leave pair.

In the former case, both words start with the letter 'e', providing an 
obvious visual pairing that doesn't exist in the latter case. Since 
we're talking about source code, the visual mnemonic means more to me 
than the exact semantics of the actual words.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From rwgk at cci.lbl.gov  Sat Jul  2 02:50:22 2005
From: rwgk at cci.lbl.gov (Ralf W. Grosse-Kunstleve)
Date: Fri, 1 Jul 2005 17:50:22 -0700 (PDT)
Subject: [Python-Dev] reducing self.x=x; self.y=y;
	self.z=z boilerplate code
Message-ID: <200507020050.j620oMbU309961@boa.lbl.gov>

Jp Calderone wrote:
> If you use vars(self).update(locals()), it even looks halfway
> pleasant ;)  I'm not sure what python-dev's current opinion of
> vars(obj) is though (I'm hoping someone'll tell me).

http://docs.python.org/lib/built-in-funcs.html#l2h-76 is pretty clear:

  vars([object])
    Without arguments, return a dictionary corresponding to the current
    local symbol table. With a module, class or class instance object
    as argument (or anything else that has a __dict__ attribute),
    returns a dictionary corresponding to the object's symbol table.
    The returned dictionary should not be modified: the effects on the
    corresponding symbol table are undefined.

> Of course, both of these fall over for __slots__'ful classes.  It'd be
> nice if there were a general way to deal with attributes of an
> instance, regardless of the implementation details of its memory
> layout.

I agree. Ideally I'd like this

  class grouping:

    __slots__ = True

    def __init__(self, .x, .y, .z):
      pass

to be equivalent to:

  class grouping:

    __slots__ = ["x", "y", "z"]

    def __init__(self, x, y, z):
      self.x = x
      del x
      self.y = y
      del y
      self.z = z
      del z

Cheers,
        Ralf

From rrr at ronadam.com  Sat Jul  2 03:04:19 2005
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 01 Jul 2005 21:04:19 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <002e01c57e86$b7915680$aa36c797@oemcomputer>
References: <002e01c57e86$b7915680$aa36c797@oemcomputer>
Message-ID: <42C5E813.8070401@ronadam.com>

Raymond Hettinger wrote:

> On a separate note, I also propose that __exit__() be renamed to
> __leave__().  The enter/leave word pairing are a better fit in standard
> English:

I tend to associate leave with leaving, and leaving with arriving.

I didn't even think the __enter__ / __exit__ names were an issue.  <shrug>

Then again there's alway  __premanage__ and __postmanage__.  That fits 
Nicks requirement for visual pairing as they both start with 'p'. And 
then calling it a manager object fits very nicely too.

Hmmm,  wonder if you could implement programs based on gant charts using 
nested manager objects?  Would the nested managers be mid-level managers?

This might have some marketing appeal to large corporations. ;-)

Ron



From jcarlson at uci.edu  Sat Jul  2 03:31:20 2005
From: jcarlson at uci.edu (Josiah Carlson)
Date: Fri, 01 Jul 2005 18:31:20 -0700
Subject: [Python-Dev] reducing self.x=x; self.y=y;
	self.z=z  boilerplate code
In-Reply-To: <42C5DC74.1040904@gmail.com>
References: <20050701232831.26278.285122888.divmod.quotient.3955@ohm>
	<42C5DC74.1040904@gmail.com>
Message-ID: <20050701182604.70C7.JCARLSON@uci.edu>


Nick Coghlan <ncoghlan at gmail.com> wrote:
> Jp Calderone wrote:
> > If you use vars(self).update(locals()), it even looks halfway
> > pleasant ;)  I'm not sure what python-dev's current opinion of
> > vars(obj) is though (I'm hoping someone'll tell me).
> > 
> > Of course, both of these fall over for __slots__'ful classes.  It'd
> > be nice if there were a general way to deal with attributes of an
> > instance, regardless of the implementation details of its memory
> > layout.
> 
> That's where PJE's more generic approach comes in:
> 
>       def initialize(ob, args, excluded=['self']):
>           for k in excluded:
>               if k in args:
>                   del args[k]
>           for k, v in args.items():
>               setattr(ob,k,v)
> 
>       class grouping:
>           def __init__(self, x, y, z):
>               initialize(self, locals())

I'm with everyone else on this, -1 on .x syntax.  As provided in the 6
line function above, everything desired is available.

You want something that you don't need to use the excluded argument for,
but still has the same stench as what Ralf originally offered?

      def initialize(ob, args):
          for k, v in args.items():
              if k[:1] == '_':
                  setattr(ob,k[1:],v)

      class grouping:
          def __init__(self, _x, _y, _z):
              initialize(self, locals())

Now, don't get me wrong, definining __slots__ can be a pain in the
tookus, but with a proper metaclass, that metaclass can define the
__slots__ attribute based on the argument list for __init__().

There you go.  A syntax change is wholly unnecessary.

 - Josiah


From nyamatongwe at gmail.com  Sat Jul  2 04:08:27 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sat, 2 Jul 2005 12:08:27 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <r7ej9g91.fsf@python.net>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<Pine.LNX.4.62.0506262014050.18093@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050626204633.02102cc8@mail.telecommunity.com>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com> <r7ej9g91.fsf@python.net>
Message-ID: <50862ebd050701190823dde486@mail.gmail.com>

Thomas Heller:

> OTOH, Python is lacking a lot when you have to handle unicode strings on
> sys.path, in command line arguments, environment variables and maybe
> other places.  

   A new patch #1231336 "Add unicode for sys.argv, os.environ,
os.system" is now in SourceForge. New parallel features sys.argvu and
os.environu are provided and os.system accepts unicode arguments
similar to PEP 277. A screenshot showing why the existing features are
inadequate and the new features an enhancement are at
http://www.scintilla.org/pyunicode.png
   One problem is that when using "python -c cmd args", sys.argvu
includes the "cmd" but sys.argv does not. They both contain the "-c".
   os.system was changed to make it easier to add some test cases but
then that looked like too much trouble. There are far too many
variants on exec*, spawn* and popen* to write a quick patch for these.

   Neil

From rwgk at cci.lbl.gov  Sat Jul  2 05:19:10 2005
From: rwgk at cci.lbl.gov (Ralf W. Grosse-Kunstleve)
Date: Fri, 1 Jul 2005 20:19:10 -0700 (PDT)
Subject: [Python-Dev]  reducing self.x=x; self.y=y; self.z=z boilerplate code
Message-ID: <200507020319.j623JAUu311991@boa.lbl.gov>

Josiah Carlson wrote:
> Now, don't get me wrong, definining __slots__ can be a pain in the
> tookus, but with a proper metaclass, that metaclass can define the
> __slots__ attribute based on the argument list for __init__().
> 
> There you go.

Where? The meta-class idea sounds interesting. Could you work it out?

> A syntax change is wholly unnecessary.

I wonder why everybody gets so agitated about a syntax enhancement
proposal. I am not proposing a syntax change!

I know enhancing the syntax is work, but shouldn't a syntax leading to
less code clutter be the higher value? IMO a long-term gain counts for
much more than avoiding a one-time investment implementing a useful
feature. Take, for example, the syntax enhancement supporting "import
foo as bar". I could just as easily write:

  import foo
  bar = foo
  del foo

"A syntax change is wholly unnecessary."
Why was it important enough anyway? It was a good enhancement because
it is clearly more expressive and reduces clutter.

In my experience the self.x=x; self.y=y etc. problem arises much more
often than the problem solved by "import foo as bar". IMO a *built-in*
solution is much more important in practice. Why does everybody have to
reinvent the adopt_init_args/initialize wheel, or have to sheepishly
type self.x=x...?

I am not wedded to the .x idea, but counter-proposals should be at
least approximately as powerful as what I propose.

>     class grouping:
>         def __init__(self, _x, _y, _z):
>             initialize(self, locals())

The "_x" alternative looks interesting but is problematic: it doesn't
have a special meaning so far, but it is also not a syntax error.
You are also not getting rid of the odd (from a learner's viewpoint)
requirement to stick in "locals()".

Remember where Python comes from: it goes back to a teaching language,
enabling non-geeks to write programs. "initialize(self, locals())"
doesn't fit that bill, especially if you have to import initialize
first. In contrast

          def __init__(self, .x, .y, .z):
                       ^^^^^^^^
almost looks like      ^^^^^^
                       self.x

and should therefore be easy to learn and remember.
I'd also be happy with

          def __init__(self, self.x, self.y, self.z):

which wouldn't be too different from unpacking tuples (and is currently
a syntax error).
However, remember, elegance = power/length. .x above has the same power
as self.x, but is shorter, therefore more elegant. :)

Hoping-that-this-leads-to-some-consensus-for-a-*built-in*-solution-ly yours,
        Ralf

From ncoghlan at gmail.com  Sat Jul  2 06:05:29 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 02 Jul 2005 14:05:29 +1000
Subject: [Python-Dev] reducing self.x=x; self.y=y;
 self.z=z boilerplate code
In-Reply-To: <200507020319.j623JAUu311991@boa.lbl.gov>
References: <200507020319.j623JAUu311991@boa.lbl.gov>
Message-ID: <42C61289.80909@gmail.com>

Ralf W. Grosse-Kunstleve wrote:
> I know enhancing the syntax is work, but shouldn't a syntax leading to
> less code clutter be the higher value? IMO a long-term gain counts for
> much more than avoiding a one-time investment implementing a useful
> feature. Take, for example, the syntax enhancement supporting "import
> foo as bar". I could just as easily write:
> 
>   import foo
>   bar = foo
>   del foo
> 
> "A syntax change is wholly unnecessary."
> Why was it important enough anyway? It was a good enhancement because
> it is clearly more expressive and reduces clutter.
> 
> In my experience the self.x=x; self.y=y etc. problem arises much more
> often than the problem solved by "import foo as bar". IMO a *built-in*
> solution is much more important in practice. Why does everybody have to
> reinvent the adopt_init_args/initialize wheel, or have to sheepishly
> type self.x=x...?

Actually, this reminds me of a recent suggestion (from AMK?) about 
being able to get at both the packed and unpacked form of an argument via:

   def f(arg as (a, b, c)):
       print arg
       print c, b, a

Then f([1, 2, 3]) would print:
   [1, 2, 3]
   3 2 1

If the right hand side of 'as' permitted the same forms as are going 
to be permitted for the 'as' clause in 'with' statements, then Ralf's 
situation could be handled via:

   def __init__(self as s, x as s.x, y as s.y, z as s.z):
      pass

Essentially, it allows arguments to be given two names - a public name 
(before the 'as', used for keyword arguments), and a private name 
(after the 'as', not used for keyword arguments, allows easy shorthand 
aliasing of self, unpacking of tuple arguments, and easy assignment of 
instance variables).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From aahz at pythoncraft.com  Sat Jul  2 06:37:11 2005
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 1 Jul 2005 21:37:11 -0700
Subject: [Python-Dev] reducing self.x=x; self.y=y;
	self.z=z boilerplate code
In-Reply-To: <200507012259.j61MxkBv308450@boa.lbl.gov>
References: <200507012259.j61MxkBv308450@boa.lbl.gov>
Message-ID: <20050702043710.GA24827@panix.com>

On Fri, Jul 01, 2005, Ralf W. Grosse-Kunstleve wrote:
> 
> I often find myself writing:
> 
>   class grouping:
> 
>       def __init__(self, x, y, z):
>           self.x = x
>           self.y = y
>           self.z = z
> 
> I hate it, and every time I show this to a Python newcomer I get that
> skeptic look. How about this for a change?
> 
>   class grouping:
> 
>       def __init__(self, .x, .y, .z):
>           pass

This is off-topic for python-dev.  Please take it to comp.lang.python.
(It's not immediately obvious that this is off-topic, I know, but please
take my word for it.)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From anthony at interlink.com.au  Sat Jul  2 07:15:41 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sat, 2 Jul 2005 15:15:41 +1000
Subject: [Python-Dev] reducing self.x=x; self.y=y;
	self.z=z boilerplate code
In-Reply-To: <200507012259.j61MxkBv308450@boa.lbl.gov>
References: <200507012259.j61MxkBv308450@boa.lbl.gov>
Message-ID: <200507021515.43755.anthony@interlink.com.au>

On Saturday 02 July 2005 08:59, Ralf W. Grosse-Kunstleve wrote:
> I hate it, and every time I show this to a Python newcomer I get that
> skeptic look. How about this for a change?
>
>   class grouping:
>
>       def __init__(self, .x, .y, .z):
>           pass

-1. Syntax should not look like grit on my monitor.

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

From reinhold-birkenfeld-nospam at wolke7.net  Sat Jul  2 09:02:52 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Sat, 02 Jul 2005 09:02:52 +0200
Subject: [Python-Dev] reducing self.x=x; self.y=y;
	self.z=z boilerplate code
In-Reply-To: <42C61289.80909@gmail.com>
References: <200507020319.j623JAUu311991@boa.lbl.gov>
	<42C61289.80909@gmail.com>
Message-ID: <da5dob$a0q$1@sea.gmane.org>

Nick Coghlan wrote:

[...]

> If the right hand side of 'as' permitted the same forms as are going 
> to be permitted for the 'as' clause in 'with' statements, then Ralf's 
> situation could be handled via:
> 
>    def __init__(self as s, x as s.x, y as s.y, z as s.z):
>       pass
> 
> Essentially, it allows arguments to be given two names - a public name 
> (before the 'as', used for keyword arguments), and a private name 
> (after the 'as', not used for keyword arguments, allows easy shorthand 
> aliasing of self, unpacking of tuple arguments, and easy assignment of 
> instance variables).

There once was a suggestion like this on c.l.py, expanding this to other
statements, like:

if re.match('a.*b', text) as m:
    # do something

What has become of this? It seems to be a wanted feature, and while I concur
that classic 'C-style' assignment-as-expression is undesirable (because of
the =/== bug-source), this would be a way, wouldn't it?

Reinhold

-- 
Mail address is perfectly valid!


From jcarlson at uci.edu  Sat Jul  2 09:12:48 2005
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sat, 02 Jul 2005 00:12:48 -0700
Subject: [Python-Dev] reducing self.x=x; self.y=y;
	self.z=z boilerplate code
In-Reply-To: <200507020319.j623JAUu311991@boa.lbl.gov>
References: <200507020319.j623JAUu311991@boa.lbl.gov>
Message-ID: <20050701224100.70CA.JCARLSON@uci.edu>


"Ralf W. Grosse-Kunstleve" <rwgk at cci.lbl.gov> wrote:
> Josiah Carlson wrote:
> > Now, don't get me wrong, definining __slots__ can be a pain in the
> > tookus, but with a proper metaclass, that metaclass can define the
> > __slots__ attribute based on the argument list for __init__().
> > 
> > There you go.
> 
> Where? The meta-class idea sounds interesting. Could you work it out?

I had assumed that you were a 'go-getter', and that you would want to
figure it out yourself.  Apparently I was wrong.

Being that I don't use metaclasses (I don't need the functionality), I
had to spend 10 minutes learning about them, and 5 minutes implementing
the following.

class AutoSlots(type):
    def __init__(cls, name, bases, dct):
        slots = dict.fromkeys(dct.get('__slots__', []))
        if '__init__' in dct:
            init = dct['__init__']
            ifvn = init.func_code.co_varnames
            for i in xrange(init.func_code.co_argcount):
                x = ifvn[i]
                if x[:1] == '_'and x[1:] not in slots:
                    slots[x[1:]] = None
        if slots:
            dct['__slots__'] = slots.keys()
        super(AutoSlots, cls).__init__(name, bases, dct)

def InitSlots(ob, args):
    for k, v in args.items():
        if k[:1] == '_':
            setattr(ob,k[1:],v)

class Foo(object):
    __metaclass__ = AutoSlots
    def __init__(self, a, b, _x, _y=None):
        InitSlots(self, locals())

>>> foo = Foo(1,2,3)
>>> vars(foo)
{'y': None, 'x': 3}


> > A syntax change is wholly unnecessary.
> 
> I wonder why everybody gets so agitated about a syntax enhancement
> proposal. I am not proposing a syntax change!

Yes you are.  Any thing that changes syntax, necessarily is a syntax
change.  People get "agitated" because with every syntax addition, that
is just another syntax that a newbie may need to learn in order to
understand some block of code.  Further, for those of us who try to
teach about it, it is just one more little nit that students ask about.

Considering that EVERYTHING you want is possible with 17 lines of
support code (which can be tossed into site and assigned to __builtins__),
and 2 lines of boilerplate (which can be made into one metaclass line if
you are willing to do a bit more work), a syntax change is foolishness.


> I know enhancing the syntax is work, but shouldn't a syntax leading to
> less code clutter be the higher value?

Why bother if the non-syntax-change goes 99% of the way?  I've further
pushed myself to -10 for any syntax change offering during my
implementation of AutoSlots.

 - Josiah


From tjreedy at udel.edu  Sat Jul  2 09:35:43 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 2 Jul 2005 03:35:43 -0400
Subject: [Python-Dev] reducing self.x=x; self.y=y;
	self.z=z boilerplate code
References: <200507020319.j623JAUu311991@boa.lbl.gov>
Message-ID: <da5flt$d7j$1@sea.gmane.org>


"Ralf W. Grosse-Kunstleve" <rwgk at cci.lbl.gov> wrote in message 
news:200507020319.j623JAUu311991 at boa.lbl.gov...
> I'd also be happy with
>
>          def __init__(self, self.x, self.y, self.z):
>
> which wouldn't be too different from unpacking tuples

If you are willing to require that the args be passed as a tuple (extra 
pair of parens) I believe you could do

    def __init__(s, args):
        s.x, s.y, s.z = args

This even checks for correct number of actual args.  I believe part of your 
underlying point is that you do not (usually) in this type of situation 
really need or want the args to be separately named locals since you just 
want to attach them to the instance.

(Way too late, may have made an error.)

Terry J. Reedy




From facundobatista at gmail.com  Sat Jul  2 11:06:26 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 2 Jul 2005 06:06:26 -0300
Subject: [Python-Dev] Money module
In-Reply-To: <001201c57e6e$83056b80$aa36c797@oemcomputer>
References: <e04bdf31050701094357ea5f84@mail.gmail.com>
	<001201c57e6e$83056b80$aa36c797@oemcomputer>
Message-ID: <e04bdf310507020206542643a5@mail.gmail.com>

On 7/1/05, Raymond Hettinger <python at rcn.com> wrote:

> [Facundo]
> > The pre-PEP is almost done, and the corresponding
> > test cases are all written.
> 
> What is the part about the pre-PEP?  Something like this probably
> shouldn't go in the standard library until it has been proven in the
> field.  This doubly true for a module that has made some unusual OO

Well, maybe the pre-PEP is not a good name.

My {name:concept} mapping for pre-PEP is something like "document that
has all the reasons, rationale and examples and everything like a good
PEP, but it's not a PEP yet (maybe never won't be)".

Making a pre-PEP, and not filling a bunch of other documents, is a
good way for me to document everything as it should be.


> * The exchange rate mechanism may end-up not being workable as it does
> not incorporate rate changes over time, differing forward and reverse
> rates, non-linear factors such as commission/fees, source currency, or
> multiple suppliers.

Are you talking about the exch_rate attribute of Currency? Our idea
for it is to record the necessary exchange rates, *at creation time*,
between the object's currency type and whatever you'd like to store.

 
> * Time value of money computations are typically dimensionless (not
> sensitive to currency type or formatting) and they often have algorithm
> specific rounding needs (round at the end of compounding period or each
> year or only at the end).

We think that it'd nice to have TVM functions inside a money module,
so if you want to do some math abouth this you just import the module
and use it.

It's not so much related to Currency data type, it's just that we
think that this module is the right place to put those functions.
Don't think that these generic functions use in some way the Currency
data type of its Context.

 
> * The absence of a division operator may prove problematic for
> allocation routines.

In what sense? I don't understand what you mean, sorry.

BTW, we take out the "/" operator because it's to tricky to use for
the final user. Being (in the context) dec_places=2 and
trap_inexact=True (both defaults), doing Currency(1)/2 is ok, but
doing Currency(1)/3 will give you an exception.

So, the idea is the user to don't have a division operator, for him to
have to look at distrib() method, and be aware of all the issues
involved.

Another concept we discussed here is that Currency() should do money
operations *only*, as safer as we could. If you want to start doing
some generic arithmetic operations, like calculating the average
between a list of prices, you should convert it to Decimal and use it
as a number and not a currency.

Take note that we're not against using currency as a number *if and
only if* it won't affect your currency behaviour (or safety).

 
> * Usually numeric formatting is kept independent from the rest of the
> design.  It will be interesting to see how workable it is to make it
> part of the Context object.  In Excel for instance, formatting is a

We put the formatting configuration in the context, because we thought
is the best way to store your config, change it for one thread, change
it for all threads, use a different formatting from another specific
context, etc... basically, the same liberty that gives you the context
for the other configuration, but for the formatting.

The formatting function itself will be a separate function in the code
(*cough* we'll use your function from Decimal recipe *cough*).


> While the Money module remains experimental, it should remain a
> third-party package.

Indeed! And maybe will still be a third-party package after it
finished being experimental.

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From rwgk at cci.lbl.gov  Sat Jul  2 12:12:18 2005
From: rwgk at cci.lbl.gov (Ralf W. Grosse-Kunstleve)
Date: Sat, 2 Jul 2005 03:12:18 -0700 (PDT)
Subject: [Python-Dev] reducing self.x=x; self.y=y;
	self.z=z boilerplate code
Message-ID: <200507021012.j62ACIGW318653@boa.lbl.gov>

Aahz wrote:
> This is off-topic for python-dev.  Please take it to comp.lang.python.
> (It's not immediately obvious that this is off-topic, I know, but please
> take my word for it.)

Done:

    http://mail.python.org/pipermail/python-list/2005-July/288292.html

Sorry for creating so much noise here.

Cheers,
        Ralf

From aahz at pythoncraft.com  Sat Jul  2 14:53:32 2005
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 2 Jul 2005 05:53:32 -0700
Subject: [Python-Dev] Money module
In-Reply-To: <e04bdf310507020206542643a5@mail.gmail.com>
References: <e04bdf31050701094357ea5f84@mail.gmail.com>
	<001201c57e6e$83056b80$aa36c797@oemcomputer>
	<e04bdf310507020206542643a5@mail.gmail.com>
Message-ID: <20050702125331.GA27568@panix.com>

On Sat, Jul 02, 2005, Facundo Batista wrote:
> On 7/1/05, Raymond Hettinger <python at rcn.com> wrote:
>> 
>> * Time value of money computations are typically dimensionless (not
>> sensitive to currency type or formatting) and they often have algorithm
>> specific rounding needs (round at the end of compounding period or each
>> year or only at the end).
> 
> We think that it'd nice to have TVM functions inside a money module,
> so if you want to do some math abouth this you just import the module
> and use it.
> 
> It's not so much related to Currency data type, it's just that we
> think that this module is the right place to put those functions.
> Don't think that these generic functions use in some way the Currency
> data type of its Context.

Sounds like a better way to go is a Money package (or perhaps a Financial
package) and just create the Currency module within it for now.  Anyway,
given that this isn't going to be a real PEP any time soon, please
restrict the discussion to comp.lang.python.  Thanks for your help
keeping python-dev clutter-free.  ;-)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From jeff at taupro.com  Sun Jul  3 04:04:31 2005
From: jeff at taupro.com (Jeff Rush)
Date: Sat, 2 Jul 2005 21:04:31 -0500
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <200507011145.22960.fdrake@acm.org>
References: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
	<200507011145.22960.fdrake@acm.org>
Message-ID: <200507022104.31983.jeff@taupro.com>

On Friday 01 July 2005 10:45 am, Fred L. Drake, Jr. wrote:
> On Friday 01 July 2005 11:44, Phillip J. Eby wrote:
>  > Resource managers.
>
> Yeah, I was thinking that, but was somewhat ambivalent.  But I definately
> like it better than anything else proposed so far.

I like that as well.  My hat in the ring would be "brackets" or "bracketed 
statements", implying there is something before, after and in the middle.  
Also not an acronym, and short.

And while we're on naming issues...

Regarding __enter__/__exit__ versus __enter__/__leave__, I like the latter not 
only because of ASM history but that the two are the same length, making 
documentation cleaner in some cases.

    ENTER:   blah blah
    LEAVE:   blah blah

A minor item, but then I'm big on visual symmetry. ;-)

-Jeff

From rrr at ronadam.com  Sun Jul  3 04:40:06 2005
From: rrr at ronadam.com (Ron Adam)
Date: Sat, 02 Jul 2005 22:40:06 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>
Message-ID: <42C75006.6090902@ronadam.com>

Raymond Hettinger wrote:

> Hmm, that got me to thinking a bit more.  Here's another subjective two
> cents worth.  "exit" seems to be a more global concept and "leave" seems
> more local.  For instance, I leave a room but exit a building.  In
> Python, sys.exit and os._exit are grand exits rather than local exits
> for functions or modules.

Yes, but it's not simply an enter, or an exit.  The most accurate 
association I can think of is "initiate" and "finalize".  They indicate 
a process is being done on the way in and out, where as "enter", "leave" 
and "exit" do not.  But the context might vary depending on what is 
actually being done so it has to remain fairly general.

The words "enter" and "exit" are nice because they are fairly straight 
forward, familiar, and short to type.  But they don't really imply any 
association to the with blocks.  So they may be on the side of being too 
general.

An alternative that has been associated to blocks in other languages is 
"begin" and "end".  So it could be a "Resource Manager Block", which 
uses a "__begin__" and "__end__" method, which is defined in a "Resource 
Manger" object or a "Resource Manager Generator" object, which is called 
by the 'with' key word.

Maybe someone can rephrase that a bit better. :)

Cheers,
Ron


From ncoghlan at gmail.com  Sun Jul  3 14:59:50 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 03 Jul 2005 22:59:50 +1000
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <42C75006.6090902@ronadam.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>
	<42C75006.6090902@ronadam.com>
Message-ID: <42C7E146.4090403@gmail.com>

Ron Adam wrote:
> So it could be a "Resource Manager Block", which 
> uses a "__begin__" and "__end__" method, which is defined in a "Resource 
> Manger" object or a "Resource Manager Generator" object, which is called 
> by the 'with' key word.

Here's an initial crack at an equivalent of the current 'Iterator 
Types' in the library reference [1], which explains the iterator and 
iterable protocols. I'm starting to understand what prompted Raymond's 
original question, since the continued use of 'exited' sounds rather 
awkward (the correct English word is actually 'left'). On the other 
hand 'enter and exit' rolls off the tongue significantly better than 
'enter and leave' (the natural pairing for the latter is 'arrive and 
leave').

All of which just leads me to the conclusion that English is a screwy 
language, and I already knew that ;)

Anyway, I stuck with 'exit' for this - I prefer slightly awkard 
phrasing in the explanation to awkwardness in the pairing of the names.

"""
Suite Local Resource Management

A frequent need in programming is to ensure a particular resource is 
released promptly after it is no longer needed. The tool to achieve 
this in Python is the 'with' statement. 'with' statements can be used 
to ensure a particular resource is acquired before the contained suite 
is entered, and released when the suite is exited.

The main argument to the 'with' statement must be a resource manager - 
an object which supports the resource management protocol. This 
protocol consists of two methods:

   __enter__():
     Called without arguments before execution enters the contained 
suite. Resource managers will generally acquire the resource in this 
method, although some resource managers may accept the resource to be 
managed as an argument to the constructor or acquire it during 
construction.
     The value returned from this method is assigned to the target 
identified in the 'as' clause of the 'with' statement.

   __exit__(exc_type, exc_value, exc_traceback):
     Called as execution exits the contained suite. If the suite was 
exited due to an exception, the details of that exception are passed 
as arguments. Otherwise, all three arguments are set to None.
     Resource managers will generally release the resource in this method.
     If the suite was exited due to an exception, and this method 
returns without incident, then the original exception continues to 
propagate. Otherwise, the exception raised by this method will replace 
the original exception.

While the primary purpose of the resource management protocol is to 
manage simple resources such as files, locks or database connections, 
more complex uses, such as automatic exception logging or transaction 
handling, are also possible.

Some resources (e.g. thread.Lock) will support the resource management 
protocol directly, acting as their own managers.

In conjunction with the 'resource_manager' decorator, Python's 
generators provide a convenient way to implement the resource 
management protocol, and share state between the __enter__ and 
__exit__ methods. The generator must contain a single yield statement. 
The generator is executed up to that point as part of the resource 
manager's __enter__ method, and the value yielded is returned. The 
remainder of the generator is executed as part of the __exit__ method. 
Any exceptions that occur in the managed suite will be injected at the 
location of the yield statement.

For example, the following resource manager allows prompt closure of 
any resource with a 'close' method (e.g. a generator or file):

   @resource_manager
   def closing(resource):
       try:
           yield resource
       finally:
           resource.close()
"""

Cheers,
Nick.

[1] http://docs.python.org/lib/typeiter.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From aahz at pythoncraft.com  Sun Jul  3 15:23:24 2005
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 3 Jul 2005 06:23:24 -0700
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <42C7E146.4090403@gmail.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>
Message-ID: <20050703132324.GA14361@panix.com>

On Sun, Jul 03, 2005, Nick Coghlan wrote:
>
>   [...]
> Anyway, I stuck with 'exit' for this - I prefer slightly awkard 
> phrasing in the explanation to awkwardness in the pairing of the names.
> 
>   [...]
>    __exit__(exc_type, exc_value, exc_traceback):
>      Called as execution exits the contained suite. If the suite was 
> exited due to an exception, the details of that exception are passed 
> as arguments. Otherwise, all three arguments are set to None.

My take is that the primary awkwardness results from all the "ex":
"execution", "exits", "exception".  If we care, I guess "leave" is okay.

Nice work!
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From mwh at python.net  Sun Jul  3 16:04:52 2005
From: mwh at python.net (Michael Hudson)
Date: Sun, 03 Jul 2005 15:04:52 +0100
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
	(Phillip J. Eby's message of "Fri, 01 Jul 2005 11:44:16 -0400")
References: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
Message-ID: <2my88ovvcr.fsf@starship.python.net>

"Phillip J. Eby" <pje at telecommunity.com> writes:

> At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote:
>>With 343 accepted, we can now add __enter__() and __exit__() methods to
>>objects.
>>
>>What term should describe those objects in the documentation?
>
> Resource managers.

Thing is, there may be no resource; in my talk at EuroPython:

    http://starship.python.net/crew/mwh/recexc.pdf

I used a with statement to establish and dis-establish an error
handler -- would you call that a resource?

Cheers,
mwh

-- 
  The meaning of "brunch" is as yet undefined.
                                             -- Simon Booth, ucam.chat

From jcarlson at uci.edu  Sun Jul  3 19:25:19 2005
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sun, 03 Jul 2005 10:25:19 -0700
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <2my88ovvcr.fsf@starship.python.net>
References: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
	<2my88ovvcr.fsf@starship.python.net>
Message-ID: <20050703102240.70DF.JCARLSON@uci.edu>


Just because not all cars are used as vehicles, does that mean that cars
are not vehicles?

There may be cases where the object being managed is not a resource
per-se, but that doesn't mean that the mechanism is misnamed as a
'resource manager'; it's just the most common use case that any of us
have managed to think of (as of yet).

 - Josiah


Michael Hudson <mwh at python.net> wrote:
> 
> "Phillip J. Eby" <pje at telecommunity.com> writes:
> 
> > At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote:
> >>With 343 accepted, we can now add __enter__() and __exit__() methods to
> >>objects.
> >>
> >>What term should describe those objects in the documentation?
> >
> > Resource managers.
> 
> Thing is, there may be no resource; in my talk at EuroPython:
> 
>     http://starship.python.net/crew/mwh/recexc.pdf
> 
> I used a with statement to establish and dis-establish an error
> handler -- would you call that a resource?


From rrr at ronadam.com  Sun Jul  3 20:02:21 2005
From: rrr at ronadam.com (Ron Adam)
Date: Sun, 03 Jul 2005 14:02:21 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <42C7E146.4090403@gmail.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	<42C75006.6090902@ronadam.com>
	<42C7E146.4090403@gmail.com>
Message-ID: <42C8282D.8050905@ronadam.com>

Nick Coghlan wrote:

> On the other hand 'enter and exit' rolls off the tongue
> significantly better than 'enter and leave'

My only concern is enter and exit may be too general.  They are
frequently used in other places, although __enter__ and __exit__ are
less common, so maybe it's a non issue.

The terms __begin__ and __end__, are nearly as general, but they stress
better that there are three parts, a beginning, middle and ending.


> All of which just leads me to the conclusion that English is a screwy
> language, and I already knew that ;)

I nowe that tue, but fixxing it issint backward compattibbal. ;-)


> Anyway, I stuck with 'exit' for this - I prefer slightly awkard 
> phrasing in the explanation to awkwardness in the pairing of the names.


After reading Michael Hudsun's post:

>>I used a with statement to establish and dis-establish an error
>>handler -- would you call that a resource?

He has a good point, maybe we are confusing what a with-block does, with
how it can be used.

So something along the lines of ...

"""
With-Mangager Blocks

A With-Manager Block is used to combine related initiation and
finalization routines from a Manager object with a local block of code.
Python will attempt to execute the finalization routine even if an error
occurs which makes With-Manager Blocks useful for writing algorithms
which require dependable closure or release of an acquired resource
after the code block is executed.

etc... """


That's a nice start on the docs Nick.

Cheers,
Ron




From michael.walter at gmail.com  Sun Jul  3 20:14:24 2005
From: michael.walter at gmail.com (Michael Walter)
Date: Sun, 3 Jul 2005 14:14:24 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <42C8282D.8050905@ronadam.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>
	<42C8282D.8050905@ronadam.com>
Message-ID: <877e9a17050703111429cdaf7c@mail.gmail.com>

How about simply "with block" or "guarded scope" or something like that?

Michael

On 7/3/05, Ron Adam <rrr at ronadam.com> wrote:
> Nick Coghlan wrote:
> 
> > On the other hand 'enter and exit' rolls off the tongue
> > significantly better than 'enter and leave'
> 
> My only concern is enter and exit may be too general.  They are
> frequently used in other places, although __enter__ and __exit__ are
> less common, so maybe it's a non issue.
> 
> The terms __begin__ and __end__, are nearly as general, but they stress
> better that there are three parts, a beginning, middle and ending.
> 
> 
> > All of which just leads me to the conclusion that English is a screwy
> > language, and I already knew that ;)
> 
> I nowe that tue, but fixxing it issint backward compattibbal. ;-)
> 
> 
> > Anyway, I stuck with 'exit' for this - I prefer slightly awkard
> > phrasing in the explanation to awkwardness in the pairing of the names.
> 
> 
> After reading Michael Hudsun's post:
> 
> >>I used a with statement to establish and dis-establish an error
> >>handler -- would you call that a resource?
> 
> He has a good point, maybe we are confusing what a with-block does, with
> how it can be used.
> 
> So something along the lines of ...
> 
> """
> With-Mangager Blocks
> 
> A With-Manager Block is used to combine related initiation and
> finalization routines from a Manager object with a local block of code.
> Python will attempt to execute the finalization routine even if an error
> occurs which makes With-Manager Blocks useful for writing algorithms
> which require dependable closure or release of an acquired resource
> after the code block is executed.
> 
> etc... """
> 
> 
> That's a nice start on the docs Nick.
> 
> Cheers,
> Ron
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com
>

From gvanrossum at gmail.com  Sun Jul  3 20:28:17 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Sun, 3 Jul 2005 11:28:17 -0700
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <50862ebd05063016466f3e6abd@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<5.1.1.6.0.20050626133610.03652688@mail.telecommunity.com>
	<Pine.LNX.4.62.0506262014050.18093@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050626204633.02102cc8@mail.telecommunity.com>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
Message-ID: <ca471dc2050703112845321ad3@mail.gmail.com>

On 6/30/05, Neil Hodgson <nyamatongwe at gmail.com> wrote:
>    One benefit I see for the path module is that it makes it easier to
> write code that behaves correctly with unicode paths on Windows.
> Currently, to implement code that may see unicode paths, you must
> first understand that unicode paths may be an issue, then write
> conditional code that uses either a string or unicode string to hold
> paths whenever a new path is created.

Then maybe the code that handles Unicode paths in arguments should be
fixed rather than adding a module that encapsulates a work-around...

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

From python at rcn.com  Sun Jul  3 20:48:50 2005
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 3 Jul 2005 14:48:50 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <877e9a17050703111429cdaf7c@mail.gmail.com>
Message-ID: <000101c57fff$dabf8620$5f21cb97@oemcomputer>

[Michael Walter]
> How about simply "with block" or "guarded scope" or something like
that?

How would you use that to describe decimal.Context() objects after Nick
adds the __enter__ and __exit__ magic methods?  We want something as
direct as, "xrange objects are iterable".


Raymond

From python at rcn.com  Sun Jul  3 20:51:03 2005
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 3 Jul 2005 14:51:03 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <42C8282D.8050905@ronadam.com>
Message-ID: <000201c58000$29f981a0$5f21cb97@oemcomputer>

[Ron Adam]
> The terms __begin__ and __end__, are nearly as general, but they
stress
> better that there are three parts, a beginning, middle and ending.

-1  Those are too generic to communicate anything.  You would be better
off using beginwith and endwith or somesuch.


Raymond

From tjreedy at udel.edu  Sun Jul  3 21:24:35 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 3 Jul 2005 15:24:35 -0400
Subject: [Python-Dev] Terminology for PEP 343
References: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
	<2my88ovvcr.fsf@starship.python.net>
Message-ID: <da9e1k$363$1@sea.gmane.org>


"Michael Hudson" <mwh at python.net> wrote in message 
news:2my88ovvcr.fsf at starship.python.net...
> Thing is, there may be no resource; in my talk at EuroPython:
>
>    http://starship.python.net/crew/mwh/recexc.pdf
>
> I used a with statement to establish and dis-establish an error
> handler -- would you call that a resource?

Yes -- now that you suggested it, given what you had on your slides ;-)

An emergency backup resource is different from a normal production resource 
(opened file for instance), but I can still see it as a resource.

Terry J. Reedy






From mwh at python.net  Sun Jul  3 21:29:07 2005
From: mwh at python.net (Michael Hudson)
Date: Sun, 3 Jul 2005 20:29:07 +0100
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <20050703102240.70DF.JCARLSON@uci.edu>
References: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
	<2my88ovvcr.fsf@starship.python.net>
	<20050703102240.70DF.JCARLSON@uci.edu>
Message-ID: <412c1fa419edec855bc719cacdba58e9@python.net>


On 3 Jul 2005, at 18:25, Josiah Carlson wrote:

> Just because not all cars are used as vehicles, does that mean that 
> cars
> are not vehicles?

No, but it means calling all vehicles "cars" is dumb.

> There may be cases where the object being managed is not a resource
> per-se, but that doesn't mean that the mechanism is misnamed as a
> 'resource manager'; it's just the most common use case that any of us
> have managed to think of (as of yet).

This is possible.  I just wanted to expand everyone's minds :)

Cheers,
mwh


From python at rcn.com  Sun Jul  3 21:41:30 2005
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 3 Jul 2005 15:41:30 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <412c1fa419edec855bc719cacdba58e9@python.net>
Message-ID: <000901c58007$36569ee0$5f21cb97@oemcomputer>

> > There may be cases where the object being managed is not a resource
> > per-se, but that doesn't mean that the mechanism is misnamed as a
> > 'resource manager'; it's just the most common use case that any of
us
> > have managed to think of (as of yet).

[Michael Hudson]
> This is possible.  I just wanted to expand everyone's minds :)

Stick by your guns.  The mechanism is more general than resource
management.  Like decorators, the encapsulation of a try/finally wrapper
is completely generic and not married to the resource management
context.


Raymond

From aahz at pythoncraft.com  Sun Jul  3 23:50:25 2005
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 3 Jul 2005 14:50:25 -0700
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000101c57fff$dabf8620$5f21cb97@oemcomputer>
References: <877e9a17050703111429cdaf7c@mail.gmail.com>
	<000101c57fff$dabf8620$5f21cb97@oemcomputer>
Message-ID: <20050703215025.GA5199@panix.com>

On Sun, Jul 03, 2005, Raymond Hettinger wrote:
> [Michael Walter]
>>
>> How about simply "with block" or "guarded scope" or something like
>> that?
> 
> How would you use that to describe decimal.Context() objects after
> Nick adds the __enter__ and __exit__ magic methods?  We want something
> as direct as, "xrange objects are iterable".

How about "decimal.Context() objects are managed resources" or "...have
guarded scopes"?  (I'm not terribly wild about either, but they are
fairly simple and direct.)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From michael.walter at gmail.com  Mon Jul  4 00:14:11 2005
From: michael.walter at gmail.com (Michael Walter)
Date: Sun, 3 Jul 2005 18:14:11 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000101c57fff$dabf8620$5f21cb97@oemcomputer>
References: <877e9a17050703111429cdaf7c@mail.gmail.com>
	<000101c57fff$dabf8620$5f21cb97@oemcomputer>
Message-ID: <877e9a1705070315144f778f12@mail.gmail.com>

Hmm:

  "Guarding a scope with a decimal.Context() object <explain effect>."

What do you think? (I'm not sure myself, but we even got a "with" in there :-)

Michael


On 7/3/05, Raymond Hettinger <python at rcn.com> wrote:
> [Michael Walter]
> > How about simply "with block" or "guarded scope" or something like
> that?
> 
> How would you use that to describe decimal.Context() objects after Nick
> adds the __enter__ and __exit__ magic methods?  We want something as
> direct as, "xrange objects are iterable".
> 
> 
> Raymond
>

From nyamatongwe at gmail.com  Mon Jul  4 02:18:15 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Mon, 4 Jul 2005 10:18:15 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <ca471dc2050703112845321ad3@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<Pine.LNX.4.62.0506262014050.18093@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050626204633.02102cc8@mail.telecommunity.com>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
	<ca471dc2050703112845321ad3@mail.gmail.com>
Message-ID: <50862ebd05070317183d971bef@mail.gmail.com>

Guido van Rossum:

> Then maybe the code that handles Unicode paths in arguments should be
> fixed rather than adding a module that encapsulates a work-around...

   It isn't clear whether you are saying this should be fixed by the
user or in the library. For a quick example, say someone wrote some
code for counting lines in a directory:

import os
root = "docs"
lines = 0
for p in os.listdir(root):
	lines += len(file(os.path.join(root,p)).readlines())
print lines, "document lines"

   Quite common code. Running it now with one file "abc" in the
directory yields correct behaviour:

>pythonw -u "xlines.py"
1 document lines

   Now copy the file "????????????" into the directory and run it again:

>pythonw -u "xlines.py"
Traceback (most recent call last):
  File "xlines.py", line 5, in ?
    lines += len(file(os.path.join(root,p)).readlines())
IOError: [Errno 2] No such file or directory: 'docs\\????????????'

   Changing line 2 to [root = u"docs"] will make the code work. If
this is the correct fix then all file handling code should be written
using unicode names.

   Contrast this to using path:

import path
root = "docs"
lines = 0
for p in path.path(root).files():
	lines += len(file(p).readlines())
print lines, "document lines"

   The obvious code works with only "abc" in the directory and also
when "????????????" is added.

   Now, if you are saying it is a library failure, then there are
multiple ways to fix it.

   1) os.listdir should always return unicode. The problem with this
is that people will see breakage of existing scripts because of
promotion issues. Much existing code assumes a fixed locale, often
8859-1 and combining unicode and accented characters will raise
UnicodeDecodeError.

   2) os.listdir should not return "???????" garbage, instead
promoting to unicode whenever it sees garbage. This may also lead to
UnicodeDecodeError as in (1).

   3) This is an exceptional situation but the exception should be
more explicit and raised earlier when os.listdir first encounters name
garbage.

   Neil

From python at rcn.com  Mon Jul  4 02:35:09 2005
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 3 Jul 2005 20:35:09 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <877e9a1705070315144f778f12@mail.gmail.com>
Message-ID: <001201c58030$3c2d1460$5f21cb97@oemcomputer>

>   "Guarding a scope with a decimal.Context() object <explain effect>."

Doesn't "guard" suggestion conditional execution?


Raymond

From pje at telecommunity.com  Mon Jul  4 04:02:33 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 03 Jul 2005 22:02:33 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <2my88ovvcr.fsf@starship.python.net>
References: <5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
	<5.1.1.6.0.20050701114330.03756ef0@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20050703215707.0266e550@mail.telecommunity.com>

At 03:04 PM 7/3/2005 +0100, Michael Hudson wrote:
>"Phillip J. Eby" <pje at telecommunity.com> writes:
>
> > At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote:
> >>With 343 accepted, we can now add __enter__() and __exit__() methods to
> >>objects.
> >>
> >>What term should describe those objects in the documentation?
> >
> > Resource managers.
>
>Thing is, there may be no resource; in my talk at EuroPython:
>
>     http://starship.python.net/crew/mwh/recexc.pdf
>
>I used a with statement to establish and dis-establish an error
>handler -- would you call that a resource?

Yes; an error handling resource is no different than say, a decimal context 
resource in this respect.  A "with" statement defines the scope of use or 
applicability of some resource; the resource manager is the object that is 
notified as to when the scope is entered and exited, so that it can 
appropriately manage the resource.

Some resources may be their own default resource manager, but it's always 
possible to create a different resource management policy by creating a new 
resource manager.

I think this is a clear and straightforward explanation of what "with" does 
and what you can do with it.


From pje at telecommunity.com  Mon Jul  4 04:10:20 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 03 Jul 2005 22:10:20 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000901c58007$36569ee0$5f21cb97@oemcomputer>
References: <412c1fa419edec855bc719cacdba58e9@python.net>
Message-ID: <5.1.1.6.0.20050703220312.0272a948@mail.telecommunity.com>

At 03:41 PM 7/3/2005 -0400, Raymond Hettinger wrote:
> > > There may be cases where the object being managed is not a resource
> > > per-se, but that doesn't mean that the mechanism is misnamed as a
> > > 'resource manager'; it's just the most common use case that any of
>us
> > > have managed to think of (as of yet).
>
>[Michael Hudson]
> > This is possible.  I just wanted to expand everyone's minds :)
>
>Stick by your guns.  The mechanism is more general than resource
>management.  Like decorators, the encapsulation of a try/finally wrapper
>is completely generic and not married to the resource management
>context.

Expand your mind.  :) "Resource" can include whatever objects you want it 
to -- or no objects at all.  A resource can be conceptual - like for 
example the user's attention, or the contents of a status bar or log 
message, or the timing/profiling of an activity.  I think maybe you're 
projecting one particular concept of "resource management" 
(acquisition/release) and therefore say it's too narrow.  But that's like 
I'm saying "vehicle", and you think that means "car".

Should we give mind-expanding examples of "resource"?  Yes, sure.  But it's 
easier to say and teach "resource management" first, and then expand the 
concept, than to start with some more nebulous concept and then say, "but 
mostly you're going to use it to manage resources of various kinds."  :)

If you did want to start with something vague, you could always call it 
"context management", and call the objects "context listeners", saying that 
the "with" statement defines a context in which its body occurs, and the 
context listener is notified of the context's entry and exit.  But I don't 
think that this really works as the primary explanation; I think it's 
better as a mind-expanding "Another way to think of this is..." add-on to 
the simple resource management explanation.


From michael.walter at gmail.com  Mon Jul  4 04:28:06 2005
From: michael.walter at gmail.com (Michael Walter)
Date: Sun, 3 Jul 2005 22:28:06 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <001201c58030$3c2d1460$5f21cb97@oemcomputer>
References: <877e9a1705070315144f778f12@mail.gmail.com>
	<001201c58030$3c2d1460$5f21cb97@oemcomputer>
Message-ID: <877e9a1705070319282481177d@mail.gmail.com>

Hmm, I think I'm seeing mostly the (guarded) entry/exit part of 
"guard" metaphor, but I see what you mean (not allowing "entry", so to
say, right?). Not sure.

Michael

On 7/3/05, Raymond Hettinger <python at rcn.com> wrote:
> >   "Guarding a scope with a decimal.Context() object <explain effect>."
> 
> Doesn't "guard" suggestion conditional execution?
> 
> 
> Raymond
>

From python at rcn.com  Mon Jul  4 05:10:33 2005
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 3 Jul 2005 23:10:33 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <877e9a1705070319282481177d@mail.gmail.com>
Message-ID: <000101c58045$f12ec4c0$5f21cb97@oemcomputer>

I'm referring to the specific meaning of "guard" in a computer science
context:

     http://www.computer-dictionary-online.org/guard.htm?q=guard

>From David Gries, The Science of Programming, if statement contains two
entities of the form B --> S wehere B is a Boolean expression and S a
command.  B --> S is called a guarded command.

I believe that terminology is rooted in Dijkstra's language of guarded
commands (used to express and facilitate program proofs).  They are
essentially the same as conditionally executed statements but may be
executed non-deterministically:

    http://cs-exhibitions.uni-klu.ac.at/contentGuardedCommand.php

Also, I believe the pattern matching part of Prolog clauses are called
guards; however, the conditional execution is deterministic (the first
match is the one that fires) and potentially recursive.

This terminology is used consistently among various functional
programming languages.  From,
http://www.cs.ecu.edu/~karl/astarte/glossary.html , "A guard in a case
is the condition that is being tested. For example, in case a => b,
expression a is the guard."

In predicate calculus, the phrase, "strengthening the guard" has a
specific meaning with the "guard" part being consistent with the above.
One example:

   http://www.cs.utexas.edu/users/psp/unity/notes/07-89.pdf

IOW, guard is a specific term, not an amorphous metaphor that can be
accurately applied to the enter/exit or enter/leave pair.


Raymond





> -----Original Message-----
> From: Michael Walter [mailto:michael.walter at gmail.com]
> Sent: Sunday, July 03, 2005 10:28 PM
> To: Raymond Hettinger
> Cc: rrr at ronadam.com; python-dev at python.org
> Subject: Re: [Python-Dev] Terminology for PEP 343
> 
> Hmm, I think I'm seeing mostly the (guarded) entry/exit part of
> "guard" metaphor, but I see what you mean (not allowing "entry", so to
> say, right?). Not sure.
> 
> Michael
> 
> On 7/3/05, Raymond Hettinger <python at rcn.com> wrote:
> > >   "Guarding a scope with a decimal.Context() object <explain
effect>."
> >
> > Doesn't "guard" suggestion conditional execution?
> >
> >
> > Raymond
> >

From python at rcn.com  Mon Jul  4 05:48:31 2005
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 3 Jul 2005 23:48:31 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <5.1.1.6.0.20050703220312.0272a948@mail.telecommunity.com>
Message-ID: <000301c5804b$3f001640$5f21cb97@oemcomputer>

> > The mechanism is more general than resource
> >management.  Like decorators, the encapsulation of a try/finally
wrapper
> >is completely generic and not married to the resource management
> >context.

[Phillip]
> Expand your mind.  :) "Resource" can include whatever objects you want
it
> to -- or no objects at all.

There is no value in expanding a concept to the point of being
meaningless (i.e. meaning whatever you want it to or nothing at all).
Instead, we need a phrase that expresses the essence of the following:


        abc = EXPR
        exc = (None, None, None)
        VAR = abc.__enter__()
        try:
            try:
                BLOCK
            except:
                exc = sys.exc_info()
                raise
        finally:
            abc.__exit__(*exc)

There is nothing in that that says resource managed.  The pre/post steps
could do almost anything from logging, to changing environments, to
translating, launching/joining unrelated threads, to communicating with
other processes, etc.  

Ideally, the phrase needs to fit in a list of all of the other
properties of the abc object (i.e.  abc objects are callable, iterable,
support the buffer interface, and are withable or somesuch).  

Another trouble with "resource managed" is that it makes little sense
even when describing something that is clearly a resource (for instance,
"locking objects are resource managed", what the heck could that mean,
there is no hint about the presence of __enter__ and __exit__ or the
ability to work with the "with" keyword).  The phrase does nothing but
suggest a particular application that historically has been implemented
without the new mechanism.

Of course, what makes this exercise hard is that our two new keywords
are prepositions and the process that they apply to is somewhat
abstract.


Raymond


P.S.  I would still like to encourage the adoption of __leave__ instead
of __exit__.  The first suggests part of an enter/leave pair.  The
latter could too easily be taken as a standalone.  If everyone doesn't
see the subtle reasons why __leave__ is better, then at least consider
__beginwith__ and __endwith__ which say exactly what they mean and are
obviously paired with each other and with the new keyword.  Remember,
these methods are going to show up in objects such as Context which are
not primarily about 343.  All of the other methods names will have
nothing to do with 343, so our choice of magic names needs to be really
good (as there will likely be NO contextual hints).


From michael.walter at gmail.com  Mon Jul  4 06:50:32 2005
From: michael.walter at gmail.com (Michael Walter)
Date: Mon, 4 Jul 2005 00:50:32 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000101c58045$f12ec4c0$5f21cb97@oemcomputer>
References: <877e9a1705070319282481177d@mail.gmail.com>
	<000101c58045$f12ec4c0$5f21cb97@oemcomputer>
Message-ID: <877e9a1705070321503c6c4063@mail.gmail.com>

Oh, I remember. Agreed, it is most probably a bad choice then.

One part of my brain likes:

  "By wrapping a block in/with[*] a decimal.Context, <elaborate on
consequences>"
  "xml.Tags used to wrap a block will print '<tag>' before the block
is entered, and '</tag>' after execution has left."

What do you think?

[*] I'm not sure what's the correct English version, sorry.. if it is
"with", it migh be a nice way to place a hyperlink to the language
reference.


On 7/3/05, Raymond Hettinger <python at rcn.com> wrote:
> I'm referring to the specific meaning of "guard" in a computer science
> context:
> 
>      http://www.computer-dictionary-online.org/guard.htm?q=guard
> 
> From David Gries, The Science of Programming, if statement contains two
> entities of the form B --> S wehere B is a Boolean expression and S a
> command.  B --> S is called a guarded command.
> 
> I believe that terminology is rooted in Dijkstra's language of guarded
> commands (used to express and facilitate program proofs).  They are
> essentially the same as conditionally executed statements but may be
> executed non-deterministically:
> 
>     http://cs-exhibitions.uni-klu.ac.at/contentGuardedCommand.php
> 
> Also, I believe the pattern matching part of Prolog clauses are called
> guards; however, the conditional execution is deterministic (the first
> match is the one that fires) and potentially recursive.
> 
> This terminology is used consistently among various functional
> programming languages.  From,
> http://www.cs.ecu.edu/~karl/astarte/glossary.html , "A guard in a case
> is the condition that is being tested. For example, in case a => b,
> expression a is the guard."
> 
> In predicate calculus, the phrase, "strengthening the guard" has a
> specific meaning with the "guard" part being consistent with the above.
> One example:
> 
>    http://www.cs.utexas.edu/users/psp/unity/notes/07-89.pdf
> 
> IOW, guard is a specific term, not an amorphous metaphor that can be
> accurately applied to the enter/exit or enter/leave pair.
> 
> 
> Raymond
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Michael Walter [mailto:michael.walter at gmail.com]
> > Sent: Sunday, July 03, 2005 10:28 PM
> > To: Raymond Hettinger
> > Cc: rrr at ronadam.com; python-dev at python.org
> > Subject: Re: [Python-Dev] Terminology for PEP 343
> >
> > Hmm, I think I'm seeing mostly the (guarded) entry/exit part of
> > "guard" metaphor, but I see what you mean (not allowing "entry", so to
> > say, right?). Not sure.
> >
> > Michael
> >
> > On 7/3/05, Raymond Hettinger <python at rcn.com> wrote:
> > > >   "Guarding a scope with a decimal.Context() object <explain
> effect>."
> > >
> > > Doesn't "guard" suggestion conditional execution?
> > >
> > >
> > > Raymond
> > >
>

From python at rcn.com  Mon Jul  4 08:34:51 2005
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 4 Jul 2005 02:34:51 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <20050703215025.GA5199@panix.com>
Message-ID: <000b01c58062$7b7458e0$5f21cb97@oemcomputer>

[Aahz]
> How about "decimal.Context() objects are managed resources" or
"...have
> guarded scopes"?  (I'm not terribly wild about either, but they are
> fairly simple and direct.)

See my other posts which bag on both "managed resources" and "guarded".
The part about scopes is less clear -- there is certainly a span of
action but the scope concept is more closely aligned with namespaces
(and we're not creating a new namespace here).

For extra credit, any proposed solution ought to also deal with the two
kinds of __enter__ methods.  One is expected to be used with "as" and
the other is not.  Neither of the above wordings begin to suggest
whether decimal.Context.__enter__ will return a useful value (the PEP
has examples of each).


Raymond

From mwh at python.net  Mon Jul  4 09:38:20 2005
From: mwh at python.net (Michael Hudson)
Date: Mon, 04 Jul 2005 08:38:20 +0100
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000301c5804b$3f001640$5f21cb97@oemcomputer> (Raymond
	Hettinger's message of "Sun, 3 Jul 2005 23:48:31 -0400")
References: <000301c5804b$3f001640$5f21cb97@oemcomputer>
Message-ID: <2mk6k7vx5f.fsf@starship.python.net>

"Raymond Hettinger" <python at rcn.com> writes:

> Another trouble with "resource managed" is that it makes little sense
> even when describing something that is clearly a resource (for instance,
> "locking objects are resource managed", what the heck could that mean,
> there is no hint about the presence of __enter__ and __exit__ or the
> ability to work with the "with" keyword).

At this point, I'm almost liking 'witherator'.  At least it's
something you can look up in the index.

(I think Raymond has identified the problem I have with resource
manager more clearly then I did; I certainly don't think I'd realise
what "decimal.Context() is a resource manager" meant at first
reading).

Cheers,
mwh

-- 
  <shapr> ucking keyoar
                                                -- from Twisted.Quotes

From gvanrossum at gmail.com  Mon Jul  4 09:44:09 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Mon, 4 Jul 2005 00:44:09 -0700
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <50862ebd05070317183d971bef@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<5.1.1.6.0.20050626204633.02102cc8@mail.telecommunity.com>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
	<ca471dc2050703112845321ad3@mail.gmail.com>
	<50862ebd05070317183d971bef@mail.gmail.com>
Message-ID: <ca471dc205070400441ab49ffb@mail.gmail.com>

> Guido van Rossum:
> > Then maybe the code that handles Unicode paths in arguments should be
> > fixed rather than adding a module that encapsulates a work-around...

On 7/3/05, Neil Hodgson <nyamatongwe at gmail.com> wrote:
>    It isn't clear whether you are saying this should be fixed by the
> user or in the library.

I meant the library.

> For a quick example, say someone wrote some
> code for counting lines in a directory:
[deleted]

Ah, sigh. I didn't know that os.listdir() behaves differently when the
argument is Unicode. Does os.listdir(".") really behave differently
than os.listdir(u".")? Bah! I don't think that's a very good design
(although I see where it comes from). Promoting only those entries
that need it seems the right solution -- user code that can't deal
with the Unicode entries shouldn't be used around directories
containing unicode -- if it needs to work around unicode it should be
fixed to support that! Mapping Unicode names to "?????" seems the
wrong behavior (and doesn't work very well once you try to do anything
with those names except for printing).

Face it. Unicode stinks (from the programmer's POV). But we'll have to
live with it. In Python 3.0 I want str and unicode to be the same data
type (like String in Java) and I want a separate data type to hold a
byte array.

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

From rrr at ronadam.com  Mon Jul  4 09:44:49 2005
From: rrr at ronadam.com (Ron Adam)
Date: Mon, 04 Jul 2005 03:44:49 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000301c5804b$3f001640$5f21cb97@oemcomputer>
References: <000301c5804b$3f001640$5f21cb97@oemcomputer>
Message-ID: <42C8E8F1.6060209@ronadam.com>

Raymond Hettinger wrote:

> There is no value in expanding a concept to the point of being
> meaningless (i.e. meaning whatever you want it to or nothing at all).
> Instead, we need a phrase that expresses the essence of the following:
> 
> 
>         abc = EXPR
>         exc = (None, None, None)
>         VAR = abc.__enter__()
>         try:
>             try:
>                 BLOCK
>             except:
>                 exc = sys.exc_info()
>                 raise
>         finally:
>             abc.__exit__(*exc)
> 
> There is nothing in that that says resource managed.  The pre/post steps
> could do almost anything from logging, to changing environments, to
> translating, launching/joining unrelated threads, to communicating with
> other processes, etc.  

The name 'abc' is the manager object, so find a better term to replace 
'abc'.

Cheers,
Ron



From ncoghlan at gmail.com  Mon Jul  4 13:14:15 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 04 Jul 2005 21:14:15 +1000
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <42C7E146.4090403@gmail.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	<42C75006.6090902@ronadam.com>
	<42C7E146.4090403@gmail.com>
Message-ID: <42C91A07.9030402@gmail.com>

Take II on some draft docs (accuracy of specific examples obviously 
depends on other PEP 343 and PEP 342 related updates).

Based on the various discussions, the following suggests the term 
"suite managers". That focuses on the fact that we're doing something 
before and after the contained suite.

The fact that they bracket a single suite seems to be the only thing 
the assorted uses really have in common, and emphasising that seems to 
work well. It's certainly the first case where I've been able to 
easily explain what decimal.Context does (or will do) when used in a 
'with' statement.

Cheers,
Nick.

"""
With Statements and Suite Management

A frequent need in programming is to ensure a particular action is
taken after a specific section of code has been executed (e.g. closing 
a file, or releasing a lock). The tool to achieve this in Python is 
the 'with' statement. 'with' statements are used to ensure a 
particular action is taken before the contained suite is entered, and 
a second action when the suite is exited.

The precise behaviour of the 'with' statement is governed by the 
supplied suite manager - an object which supports the suite management
protocol. This protocol consists of two methods:

    __enter__(self):
      This method is called without arguments before the contained 
suite is entered. If the 'as' clause of the 'with' statement is used, 
the value returned from this method is assigned to the identified target.
      Many suite managers will return self from the __enter__ method, 
but returning a different object may make sense for some managers 
(e.g. see the 'closing' suite manager example below).

    __exit__(self, exc_type, exc_value, exc_traceback):
      This method is called after the contained suite has exited. If 
the suite was left due to an exception, the details of that exception 
are passed as arguments. Otherwise, all three arguments are set to None.
      If exception details are passed in, and this method returns 
without incident, then the original exception continues to propagate. 
Otherwise, the exception raised by this method will replace the 
original exception.

Using Suite Managers to Manage Resources

The simplest use of suite management is to strictly control the 
handling of key resources (e.g. files, generators, database 
connections, synchronisation locks).

These resource managers will generally acquire the resource in their 
__enter__ method, although some resource managers may accept the 
resource to be managed as an argument to the constructor or acquire it 
during construction. Resource managers will then release the resource 
in their __exit__ method.

Some resources (e.g. threading.Lock) support the suite management 
protocol natively, allowing them to be used directly in 'with' statements.

While resource management is the most obvious use of the suite 
management protocol, more complex uses are also possible. For example, 
when used as suite managers, decimal.Context objects set themselves as 
the current context before the suite is entered, and then 
automatically revert back to the previous context as the suite is 
exited. This allows the code in the contained suite to manipulate the 
context freely, without needing to worry about manually undoing any 
changes. Other possibilities for suite management include automatic 
exception logging or database transaction handling.

Using Generators to Define Suite Managers

In conjunction with the 'suite_manager' decorator, Python's
generators provide a convenient way to implement the suite
management protocol, and share state between the __enter__ and
__exit__ methods.

The generator must yield exactly once during normal execution. The 
suite manager's __enter__ method executes the generator up to that 
point, and the value yielded is returned. The remainder of the 
generator is executed by the suite manager's __exit__ method. Any 
exceptions that occur in the managed suite will be injected into the 
generator at the location of the yield statement.

For example, the following suite manager allows prompt closure of
any resource with a 'close' method (e.g. a generator or file):

    @suite_manager
    def closing(resource):
        try:
            yield resource
        finally:
            resource.close()
"""
-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From gvanrossum at gmail.com  Mon Jul  4 17:49:43 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Mon, 4 Jul 2005 08:49:43 -0700
Subject: [Python-Dev] floatobject.c 2.136
In-Reply-To: <2mwtocyan6.fsf@starship.python.net>
References: <005501c57cf7$233b91c0$8d0ba044@oemcomputer>
	<2mwtocyan6.fsf@starship.python.net>
Message-ID: <ca471dc205070408492d14540a@mail.gmail.com>

[Raymond Hettinger]
> > I'm getting a compiler warning from your checkin:

[Michael Hudson]
> "your"?  Mine?

Alas, a typical exchange. The checkins are mailed from the committer's
Sf email address, but the mailing list has been set up to redirect all
replies to python-dev -- if you don't catch this before sending, you
may be embarrassed in public or confuse the addressee.

Is this behavior of the checkins list really a good idea?

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

From pje at telecommunity.com  Mon Jul  4 18:33:20 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 04 Jul 2005 12:33:20 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000301c5804b$3f001640$5f21cb97@oemcomputer>
References: <5.1.1.6.0.20050703220312.0272a948@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20050704122534.02702e18@mail.telecommunity.com>

At 11:48 PM 7/3/2005 -0400, Raymond Hettinger wrote:
>Remember,
>these methods are going to show up in objects such as Context which are
>not primarily about 343.  All of the other methods names will have
>nothing to do with 343, so our choice of magic names needs to be really
>good (as there will likely be NO contextual hints).

with context_expression as variable:
     # perform actions within a context

The "with" statement establishes a context in which some operations are to 
be performed.  Often, this is a resource management context, wherein some 
resource is allocated when the context is entered, and when it is 
exited.  Or it may be a locking context, where a lock is acquired and 
released around the statements.  Or it may be a computational context, such 
as a Decimal context that controls the precision of decimal 
calculations.  In fact, it may be any context that can be defined in terms 
of behavior to be performed when the context is entered and exited.

The object produced by 'context_expression' must have __enter_context__ and 
__exit_context__ methods, which will be invoked by the "with" statement 
when the context is entered, and when it is exited for any reason (such as 
by an exception, "return" statement, or other control flow statements).

...etc.


From python at rcn.com  Mon Jul  4 19:59:49 2005
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 4 Jul 2005 13:59:49 -0400
Subject: [Python-Dev] floatobject.c 2.136
In-Reply-To: <ca471dc205070408492d14540a@mail.gmail.com>
Message-ID: <000201c580c2$2bdf6a80$e129cb97@oemcomputer>

> Alas, a typical exchange. The checkins are mailed from the committer's
> Sf email address, but the mailing list has been set up to redirect all
> replies to python-dev -- if you don't catch this before sending, you
> may be embarrassed in public or confuse the addressee.
> 
> Is this behavior of the checkins list really a good idea?

I think it should be changed.

In addition to making it a PITA to send notes to the committer, there is
another issue.  For anyone subscribing to python-dev but not the
checkins list, they see conversations started without seeing the history
of checkins that gave rise to those conversations.  Worse, the
resolution of those conversations is often another checkin (which
doesn't get cc'd to python-dev so it is not obvious when there is a
resolution).  For instance, this thread was resolved by Michael's
checkin, 2.137, but you wouldn't know that from reading python-dev.

A few years ago, the cc to python-dev was not automatic and the default
reply address was the original committer.  That worked much better.


Raymond



P.S.  I still don't follow the whole yours/mine comment from Michael.
The offending code line was part of 2.136 which CVS says was checked-in
by him on 5/27/2005 and then fixed by him on 6/30/2005.



From mwh at python.net  Mon Jul  4 20:17:59 2005
From: mwh at python.net (Michael Hudson)
Date: Mon, 4 Jul 2005 19:17:59 +0100
Subject: [Python-Dev] floatobject.c 2.136
In-Reply-To: <000201c580c2$2bdf6a80$e129cb97@oemcomputer>
References: <000201c580c2$2bdf6a80$e129cb97@oemcomputer>
Message-ID: <fa393c902e89f47df75de7a91f8991c9@python.net>

On 4 Jul 2005, at 18:59, Raymond Hettinger wrote:

> P.S.  I still don't follow the whole yours/mine comment from Michael.
> The offending code line was part of 2.136 which CVS says was checked-in
> by him on 5/27/2005 and then fixed by him on 6/30/2005.

Well, my confusion started and ended with the fact that a mail to 
python-dev with no obvious indication of being a reply to anything used 
the word "your", without a name or any indication of who you were 
addressing.  I'm afraid I don't remember the exact revisions of the 
exact files I've checked in recently :)

Cheers,
mwh


From python at rcn.com  Mon Jul  4 20:16:51 2005
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 4 Jul 2005 14:16:51 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <5.1.1.6.0.20050704122534.02702e18@mail.telecommunity.com>
Message-ID: <000301c580c4$8da6ee80$e129cb97@oemcomputer>

[Phillip J. Eby]
>
> with context_expression as variable:
>      # perform actions within a context
> 
> The "with" statement establishes a context in which some operations
are to
> be performed.  Often, this is a resource management context, wherein
some
> resource is allocated when the context is entered, and when it is
> exited.  Or it may be a locking context, where a lock is acquired and
> released around the statements.  Or it may be a computational context,
> such
> as a Decimal context that controls the precision of decimal
> calculations.  In fact, it may be any context that can be defined in
terms
> of behavior to be performed when the context is entered and exited.
> 
> The object produced by 'context_expression' must have
__enter_context__
> and
> __exit_context__ methods, which will be invoked by the "with"
statement
> when the context is entered, and when it is exited for any reason
(such as
> by an exception, "return" statement, or other control flow
statements).

This is much improved.  I think we're getting close.
So far, I like Nick's most recent version the best,
but this is in the ballpark.

The new methods names are a step in the right direction
but they are butt-ugly and unfriendly.  It is much cleaner looking
and equally communicative to write __beginwith__ and __endwith__.
Those names are clearly bookends and associated with with-suites.
They are shorter, more pithy, and don't abuse underscore conventions
(the current worst offenders are test___all__.py and the set module's
__as_temporarily_immutable__ attribute which gives me COBOL flashbacks).



[Nick Coghlan]
> Based on the various discussions, the following suggests the term
> "suite managers". That focuses on the fact that we're doing something
> before and after the contained suite.
> 
> The fact that they bracket a single suite seems to be the only thing
> the assorted uses really have in common, and emphasising that seems to
> work well. It's certainly the first case where I've been able to
> easily explain what decimal.Context does (or will do) when used in a
> 'with' statement.

I think you're onto something.  Stick with it.  Your whole write-up is
clear.  It is the first one that doesn't look like it had to twist its
metaphor into a knot.
 


Raymond

From facundobatista at gmail.com  Mon Jul  4 20:56:10 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 4 Jul 2005 15:56:10 -0300
Subject: [Python-Dev] Money module
In-Reply-To: <20050702125331.GA27568@panix.com>
References: <e04bdf31050701094357ea5f84@mail.gmail.com>
	<001201c57e6e$83056b80$aa36c797@oemcomputer>
	<e04bdf310507020206542643a5@mail.gmail.com>
	<20050702125331.GA27568@panix.com>
Message-ID: <e04bdf3105070411564478e857@mail.gmail.com>

On 7/2/05, Aahz <aahz at pythoncraft.com> wrote:

> Sounds like a better way to go is a Money package (or perhaps a Financial
> package) and just create the Currency module within it for now.  Anyway,

Something to consider!


> given that this isn't going to be a real PEP any time soon, please
> restrict the discussion to comp.lang.python.  Thanks for your help
> keeping python-dev clutter-free.  ;-)

Well, there's a separate list for the discussions, pymoney-general
(accesable through the project in SF). This post was only for tell you
people that if you're interested, this is a good moment to jump in.

Regards,

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From theller at python.net  Mon Jul  4 20:58:29 2005
From: theller at python.net (Thomas Heller)
Date: Mon, 04 Jul 2005 20:58:29 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
References: <d9mmd6$gjf$1@sea.gmane.org>
	<Pine.LNX.4.62.0506262014050.18093@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050626204633.02102cc8@mail.telecommunity.com>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com> <r7ej9g91.fsf@python.net>
	<50862ebd050701190823dde486@mail.gmail.com>
Message-ID: <7jg6csa2.fsf@python.net>

Neil Hodgson <nyamatongwe at gmail.com> writes:

> Thomas Heller:
>
>> OTOH, Python is lacking a lot when you have to handle unicode strings on
>> sys.path, in command line arguments, environment variables and maybe
>> other places.  
>
>    A new patch #1231336 "Add unicode for sys.argv, os.environ,
> os.system" is now in SourceForge. New parallel features sys.argvu and
> os.environu are provided and os.system accepts unicode arguments
> similar to PEP 277. A screenshot showing why the existing features are
> inadequate and the new features an enhancement are at
> http://www.scintilla.org/pyunicode.png
>    One problem is that when using "python -c cmd args", sys.argvu
> includes the "cmd" but sys.argv does not. They both contain the "-c".

Not only that, all the other flags like -O and -E are also in sys.argvu
but not in sys.argv.

>    os.system was changed to make it easier to add some test cases but
> then that looked like too much trouble. There are far too many
> variants on exec*, spawn* and popen* to write a quick patch for these.

Those are nearly obsoleted by the subprocess module (although I do not
know how that handles unicode.

Thomas


From steven.bethard at gmail.com  Mon Jul  4 23:35:42 2005
From: steven.bethard at gmail.com (Steven Bethard)
Date: Mon, 4 Jul 2005 15:35:42 -0600
Subject: [Python-Dev] python-dev Summary for 2005-06-16 through 2005-06-30
	[draft]
Message-ID: <d11dcfba0507041435603983d4@mail.gmail.com>

Here's our draft of the summary for the second half of June.  As
usual, please let me, Tony or Tim know if you have any comments or
corrections.

-- Steven Bethard

=====================
Summary Announcements
=====================

------------------
OSCON Registration
------------------

Though if you haven't yet registered, you've already missed the early
registration period (which ended June 20), you should still consider
taking a look at the O'Reilly Open Source Convention (OSCON). Guido
assures us that "the Python program is really good!"

Contributing Thread:

- `Please spread the word about OSCON early reg deadline
<http://mail.python.org/pipermail/python-dev/2005-June/054259.html>`__

=========
Summaries
=========

------------
PEP Clean Up
------------

Raymond Hettinger decided to go through the `list of PEPs`_ and do
some spring cleaning (late for the Northern Hemisphere, but early down
south).

* Rejection of `PEP 303`_ ("Extend divmod() for Multiple Divisors")
was proposed on the grounds that it has been open for two and half
years and hasn't generated discussion or support, is unpersuasive, and
unnecessary.  No-one spoke up for it (and some against), so it is now
rejected.

* Rejection of `PEP 254`_ ("Making Classes Look More Like Types") was
proposed on the grounds that it is only an empty stub and is unlikely
to ever get filled-out.  No-one spoke up either way, and it is now
rejected.

* Rejection of `PEP 265`_ ("Sorting Dictionaries by Value") was
proposed on the grounds that as of Python 2.4 its use case is easily
solved with a one-line sorted() solution.  Several people agreed, and
no-one disagreed, so the PEP is now rejcted.

* Rejection of `PEP 276`_ ("Simple iterator for ints") was proposed on
the grounds that the principal use case was largely met by enumerate()
and that the proposed syntax was problematic.  Guido agreed, so the
PEP was rejected.
   
* Rejection of `PEP 281`_ ("Loop Counter Iteration with range and
xrange") was proposed on the grounds that it too was solved by the
enumerate() built-in.  Guido agreed again, and this PEP too was
rejected.

* Rejection of `PEP 294`_ ("Type Names in the types Module") was
proposed on the grounds that a centralized repository of type names
was a mistake and that neither the "types" nor "new" modules should be
carried forward to Python 3.0.  No-one disagreed, and the PEP was
rejected.

* Rejection of `PEP 313`_ ("Adding Roman Numeral Literals to Python" -
yes, this is a real PEP!) was proposed, and the PEP was rejected.

* Rejection of `PEP 336`_ ("Make None Callable") was proposed on the
grounds that no support has grown beyond the original poster, and that
it fails the tests of obviousness, necessity, clarity, and
explicitness.  Many people, including Guido, agreed, and the PEP was
rejected.

* Raymond suggested updating `PEP 284`_ ("Integer for-loops"), but
several people spoke up against it, including Guido, so the PEP was
rejected.

* Raymond asked whether `PEP 330`_ ("Python Bytecode Verification")
had any known uses.  Guido said that he believes that a verification
tool has some value, but if someone wants to add it to Tools/scripts,
no PEP is required, so the PEP was rejected.

* A.M. Kuchling volunteered to take over `PEP 206`_ ("Python Advanced
Library", or the "Batteries Included" PEP) and rewrite it to describe
a set of third-party packages to complement the standard library. 
This was approved, and so he's now the maintainer.

* Raymond suggested accepting `PEP 312`_ ("Simple Implicit Lambda"),
which resulted in the most discussion of any of the PEP
recommendations.  However, Guido hates the unary colon syntax, and it
was decided that the PEP needs to go back to the drawing board and
find a more Pythonic syntax (perhaps an alternative unary operator). 
The PEP is now deferred.

* Raymond asked whether `PEP 237`_ ("Unifying Long Integers and
Integers") was now complete and could be marked as final.  Guido noted
that it was complete for 2.x, but that phase C will be implemented in
Python 3.0, as the PEP states.  He indicated that he would be fine
with marking `PEP 237`_ as final and moving this phase to `PEP 3000`_;
at the time of writing, this hadn't been done yet.

.. _list of PEPs: http://wwww.python.org/peps    
.. _PEP 303: http://www.python.org/peps/pep-0303.html
.. _PEP 265: http://www.python.org/peps/pep-0265.html
.. _PEP 254: http://www.python.org/peps/pep-0254.html
.. _PEP 276: http://www.python.org/peps/pep-0276.html
.. _PEP 281: http://www.python.org/peps/pep-0281.html
.. _PEP 294: http://www.python.org/peps/pep-0294.html
.. _PEP 313: http://www.python.org/peps/pep-0313.html
.. _PEP 336: http://www.python.org/peps/pep-0336.html
.. _PEP 284: http://www.python.org/peps/pep-0284.html
.. _PEP 330: http://www.python.org/peps/pep-0330.html
.. _PEP 206: http://www.python.org/peps/pep-0206.html
.. _PEP 312: http://www.python.org/peps/pep-0312.html
.. _PEP 237: http://www.python.org/peps/pep-0237.html
.. _PEP 3000: http://www.python.org/peps/pep-3000.html

Contributing Threads:

- `Propose rejection of PEP 303 -- Extend divmod() for Multiple
Divisors <http://mail.python.org/pipermail/python-dev/2005-June/054283.html>`__
- `Propose to close PEP 254 -- Making Classes Look More Like Types
<http://mail.python.org/pipermail/python-dev/2005-June/054357.html>`__
- `Propose to reject PEP 265 -- Sorting Dictionaries by Value
<http://mail.python.org/pipermail/python-dev/2005-June/054262.html>`__
- `Propose to reject PEP 276 -- Simple iterator for ints
<http://mail.python.org/pipermail/python-dev/2005-June/054276.html>`__
- `Propose to reject PEP 281 -- Loop Counter Iteration with range and
xrange <http://mail.python.org/pipermail/python-dev/2005-June/054263.html>`__
- `Propose to reject PEP 294 -- Type Names in the types Module
<http://mail.python.org/pipermail/python-dev/2005-June/054353.html>`__
- `Propose to reject PEP 313 -- Adding Roman Numeral Literals to
Python <http://mail.python.org/pipermail/python-dev/2005-June/054278.html>`__
- `Propose to reject PEP 336 -- Make None Callable
<http://mail.python.org/pipermail/python-dev/2005-June/054280.html>`__
- `Propose updating PEP 284 -- Integer for-loops
<http://mail.python.org/pipermail/python-dev/2005-June/054316.html>`__
- `Question about PEP 330 -- Python Bytecode Verification
<http://mail.python.org/pipermail/python-dev/2005-June/054354.html>`__
- `Request to rewrite PEP 206
<http://mail.python.org/pipermail/python-dev/2005-June/054287.html>`__
- `Recommend accepting PEP 312 -- Simple Implicit Lambda
<http://mail.python.org/pipermail/python-dev/2005-June/054303.html>`__
- `Is PEP 237 final -- Unifying Long Integers and Integers
<http://mail.python.org/pipermail/python-dev/2005-June/054305.html>`__

[TAM]


-------------------------------------------
PEP 342: Coroutines via Enhanced Generators
-------------------------------------------

Raymond Hettinger withdrew `PEP 288`_, suggesting that the
exception-handling parts were now covered in `PEP 343`_ and that the
generator-attributes part was never very popular.  Though he seemed to
think `PEP 342`_ could replace the generator-attributes part, he was
concerned that `PEP 342`_ was proposing too extensive a set of
changes, as it modified the basic for-loop and continue statement
semantics, and created a split between new- and old-style iterators.

Phillip J. Eby took over `PEP 342`_, made some changes to address
these issues, added some motivating examples, and provided a
`prototype patch`_ implementing the proposal. `PEP 342`_ no longer
modifies for-loop or continue statements or introduces a new iterator
protocol, instead choosing to modify the generator-iterator type by
adding the methods:

- send(value) which acts like the previously proposed single-argument
form of next().  (Introducing a new method instead of overloading
next() minimizes overhead for simple next() calls.)  Calling
send(value) before the generator has advanced to the first
yield-expression raises a TypeError.

- throw() which injects exceptions at the point of the generator's
last yield-expression.

- close() which injects a GeneratorExit exception into the generator
to make sure that it terminates. PEP 342 also attempts to ensure that
this close() method will be called when a generator-iterator is
garbage-collected.

Additionally, Phillip's patch addressed some garbage collection
issues, having generators set their gi_frame to None when they finish,
and modifying gcmodule.c to check for tp_del methods on instance
objects (instead of just on heap types) so that the close() methods of
generators would be properly invoked.

.. _PEP 288: http://www.python.org/peps/pep-0288.html
.. _PEP 342: http://www.python.org/peps/pep-0342.html
.. _PEP 343: http://www.python.org/peps/pep-0343.html
.. _prototype patch: http://python.org/sf/1223381

Contributing Threads:

- `Withdrawn PEP 288 and thoughts on PEP 342
<http://mail.python.org/pipermail/python-dev/2005-June/054261.html>`__
- `Implementing PEP 342 (was Re: Withdrawn PEP 288 and thoughts on PEP
342) <http://mail.python.org/pipermail/python-dev/2005-June/054309.html>`__
- `gcmodule issue w/adding __del__ to generator objects
<http://mail.python.org/pipermail/python-dev/2005-June/054334.html>`__
- `Generator enhancements patch available
<http://mail.python.org/pipermail/python-dev/2005-June/054337.html>`__

[SJB]


--------------------------------------------------
Adding Jason Ordenorff's path module to the stdlib
--------------------------------------------------

Reinhold Birkenfeld suggested that Jason Ordenorff's `path module`_
should be in the standard library as it has a large user base,
frequently c.l.py praises, is a superior interface to OS paths than
the existing os.path module, and could more easily be made to properly
support unicode paths.  Phillip J. Eby reviewed the module and made a
list of suggested changes, primarily changing so that there is only
one way to do things and clearing up naming confusion between the
module and the existing os.path module, but was generally in favour of
inclusion.  The suggestion was to call the object either "path" or
"Path" and put it either in the os module or os.path module, although
Guido vetoed os.path.path and Tony Meyer begged for more
differentiation between the path class and path module than a single
character's case.

Early enthusiasm suggested that a PEP wasn't needed to include the
module, as there was general agreement about the inclusion and all but
minor details.  Guido disagreed, however, asking whether there was a
need for a completely different mechanism for doing the same things
that os.path already does, and inevitable disgreements about details
(e.g. time in seconds, or a datetime object?) reinforced the need for
a PEP.  Discussion was still continuing at the end of the summary
period; a PEP seems the likely outcome.

.. _path module: http://www.jorendorff.com/articles/python/path/ 

Contributing Thread:

- `Adding the 'path' module (was Re: Some RFE for review)
<http://mail.python.org/pipermail/python-dev/2005-June/054439.html>`__

[TAM]


-------------------------------
PEP 304 searches for a champion
-------------------------------

Skip Montanaro wrote `PEP 304`_ ("Controlling Generation of Bytecode
Files") a couple of years ago, and has mostly sat idle other than
minor updates.  Skip has no personal use for the PEP, and can't offer
championing for it than continuing to respond to people's inputs.  He
asked whether anyone would be willing to take up championship of the
PEP, or if it could be rejected.  There were a couple of people
interested in the idea, but no-one has yet volunteered to take the PEP
from Skip.

.. _PEP 304: http://www.python.org/peps/pep-0304.html 

Contributing Threads:

- `PEP 304 - is anyone really interested?
<http://mail.python.org/pipermail/python-dev/2005-June/054419.html>`__
- `PEP 304 "Controlling Generation of Bytecode Files" - patch updated
<http://mail.python.org/pipermail/python-dev/2005-June/054264.html>`__

[TAM]


-------------------------
Merging float and Decimal
-------------------------

Fredrik Johansson suggested that Python floats and decimal.Decimal
objects should be merged together much in the way that Python ints and
longs have been. The idea would be that a binary or decimal
represenation could be selected at runtime using a context object like
decimal.Context. This would allow code like::

    >>> from __future__ import new_float_behaviour
    >>> 1.1
    1.1
    >>> import sys
    >>> sys.float_context.binary = True
    >>> 1.1
    1.1000000000000001

One issue would be the extent to which various context settings could
be respected for both binary and decimal floating-point numbers. 
Since binary floating-point numbers would be represented using C
floats, they would not have direct access to the traps and flags that
decimal.Decimal floats do because these signals are not available in
C. This issue could possibly be addressed by maintaining
platform-dependent code for accessing
traps and flags.

People seemed generally to agree with the proposal, with Raymond
Hettinger suggesting a roadmap: first move decimal.Decimal objects to
C code, next introduce decimal literals, and then perhaps use decimal
floating-point numbers as the default in Python 3.0.

Contributing Thread:

- `Decimal floats as default (was: discussion about PEP239 and 240)
<http://mail.python.org/pipermail/python-dev/2005-June/054409.html>`__

[SJB]


------------------------------------------------
API differences between builtin set and sets.Set
------------------------------------------------

Barry Warsaw noted that builtin set objects (unlike sets.Set objects) do
not have .union_update() methods as aliases for their .update() methods.
He also pointed out that the documentation for builtin set objects does
not cover the .update() method, and wrongly indicates that the set methods
only accept sequences, not iterables.

Raymond Hettinger indicated that the API change was intentional, but that
he would fix the documentation if someone assigned him an appropriate
patch.

Contributing Thread:

- `Inconsistent API for sets.Set and build-in set
<http://mail.python.org/pipermail/python-dev/2005-June/054518.html>`__

[SJB]


----------------------------------
Using the alternate form of iter()
----------------------------------

In the dowhile threads, Jp Calderone pointed out a useful case for the
alternate form of iter() which takes a no-argument function to call
repeatedly, and a sentinel value to look for::

    for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''):
        f2.write(chunk)

This started a brief discussion on how this very useful idiom could be
made easier to read. I suggested that it would be nice if iter() had a
signature like unittest.TestCase.assertRaises which accepts ``*args``
and ``**kwargs`` to be passed to the function when it is called. This
would have to be a Python 3.0 change because it's backwards
incompatible, but would look something like::

    for chunk in iter('', f1.read, CHUNK_SIZE):
        f2.write(chunk)

Benji York, Michael Hudson and James Y Knight suggested that
functional.partial (which will be available in Python 2.5) is a more
general solution because it does not require argument reordering and
it can also be used in the occasional cases that require multiple
callables::

    for chunk in iter(partial(f1.read, CHUNK_SIZE), ''):
        f2.write(chunk)

Contributing Thread:

- `iter alternate form and *args and **kwargs
<http://mail.python.org/pipermail/python-dev/2005-June/054256.html>`__

[SJB]


--------------------------------------
Adding lightweight cooperative threads
--------------------------------------

Adam Olsen outlined various problems with the current state of Python
threading (they are expensive, unpredictable, uninterupptible, fail
silently, and have finely grained atomicity), and proposed adding
lightweight cooperative threads to Python (including a new operator
for threaded calls, and new statement for creating threads).  The
proposal received no support, however, with Adam pointed towards
`Stackless Python`_ and greenlets from `the Py lib`_ as similar
solutions that do not require modification of the language.  `PEP
342`_ was also touted as a solution - the PEP includes a short (<50
lines) cooperative threading example.

.. _Stackless Python: http://www.stackless.com/ 
.. _the Py lib: http://codespeak.net/py 
.. _PEP 342: http://www.python.org/peps/pep-0342.html

Contributing Thread:

- `Adding Python-Native Threads
<http://mail.python.org/pipermail/python-dev/2005-June/054430.html>`__

[TAM]


------------------------------
Syntax for ignoring exceptions
------------------------------

Dmitry Dvoinikov proposed a shorthand for ignoring exceptions::

    ignore TypeError:
        do stuff
    [else:
        do other stuff]

which would replace::

    try:
        do stuff
    except TypeError:
        pass
    [else:
        do other stuff]

Most people seemed to think that generally the except and/or else
clauses would be non-trivial, so the savings of two lines were not
really worth the complications to the language.

Contributing Thread:

- `Explicitly declaring expected exceptions for a block
<http://mail.python.org/pipermail/python-dev/2005-June/054387.html>`__

[SJB]


----------------------------------
Proposed new serialization format.
----------------------------------

Simon Wittber proposed a pre-PEP for `RFE 46738`_, to provide a safe,
documented class for serialization of simple python types; however,
many people commented that they felt that there were already
sufficient serialization formats.  Simon felt that they were all slow,
bloated or unsafe, but wasn't able to convince anyone that there was a
need for a new format.

.. _RFE 46738: http://python.org/sf/467384

Contributing Thread:

- `PEP for RFE 46738 (first draft)
<http://mail.python.org/pipermail/python-dev/2005-June/054313.html>`__

[TAM]


---------------------------------------
Behavior of subprocess.call(stdin=PIPE)
---------------------------------------

In a followup to a `sourceforge patch`_, Stuart Bishop asked that
subprocess.call() close the input stream if it receives the keyword
argument stdin=PIPE. Since subprocess.call() creates a process and
waits for it to complete before returning, the stdin pipe is never
available to the caller and thus can never be written to while the
process is running. Stuart suggested that if subprocess.call() closed
the input stream when stdin=PIPE, subprocesses that incorrectly read
from stdin would break out with an error immediately instead of
hanging.

While people seemed to agree that the current behavior of
subprocess.call(stdin=PIPE) was mildly undesirable, there was
disagreement as to the solution. Michael Chermside suggested that
subprocess.call(stdin=PIPE) should raise an exception, while Peter
?strand felt that keeping the subprocess.call() wrapper around
subprocess.Popen() as simple as possible spoke against complicating it
with error checking code.

.. _sourceforge patch: http://www.python.org/sf/1220113

Contributing Thread:

- `subprocess.call() and stdin
<http://mail.python.org/pipermail/python-dev/2005-June/054405.html>`__

[SJB]


===============
Skipped Threads
===============

- `getch() in msvcrt does not accept extended characters.
<http://mail.python.org/pipermail/python-dev/2005-June/054506.html>`__
- `Terminology for PEP 343
<http://mail.python.org/pipermail/python-dev/2005-June/054525.html>`__
- `List copy and clear (was Re: Inconsistent API for sets.Set and
build-in set) <http://mail.python.org/pipermail/python-dev/2005-June/054522.html>`__
- `Multiple expression eval in compound if statement?
<http://mail.python.org/pipermail/python-dev/2005-June/054164.html>`__
- `refcounting vs PyModule_AddObject
<http://mail.python.org/pipermail/python-dev/2005-June/054232.html>`__
- `Some RFE for review
<http://mail.python.org/pipermail/python-dev/2005-June/054438.html>`__
- `Please spread the word about OSCON early reg deadline
<http://mail.python.org/pipermail/python-dev/2005-June/054259.html>`__
- `New python developer
<http://mail.python.org/pipermail/python-dev/2005-June/054509.html>`__
- `Possible C API problem?
<http://mail.python.org/pipermail/python-dev/2005-June/054471.html>`__
- `PyPI: no space left on device
<http://mail.python.org/pipermail/python-dev/2005-June/054331.html>`__
- `PySWT -- Python binding of SWT using GCJ + SIP
<http://mail.python.org/pipermail/python-dev/2005-June/054502.html>`__
- `Subclassing in 'C'
<http://mail.python.org/pipermail/python-dev/2005-June/054434.html>`__
- `is type a usable feature?
<http://mail.python.org/pipermail/python-dev/2005-June/054422.html>`__
- `misplaced PEP
<http://mail.python.org/pipermail/python-dev/2005-June/054377.html>`__
- `using pyhon from the MSYS shell
<http://mail.python.org/pipermail/python-dev/2005-June/054505.html>`__
- `[Python-checkins] python/dist/src/Lib Cookie.py, 1.17, 1.18
<http://mail.python.org/pipermail/python-dev/2005-June/054447.html>`__
- `[Python-checkins] python/dist/src/Tools/bgen/bgen bgenGenerator.py,
1.17, 1.18 bgenObjectDefinition.py, 1.29, 1.30 bgenType.py, 1.15, 1.16
bgenVariable.py, 1.6, 1.7 scantools.py, 1.37, 1.38
<http://mail.python.org/pipermail/python-dev/2005-June/054444.html>`__
- `floatobject.c 2.136
<http://mail.python.org/pipermail/python-dev/2005-June/054513.html>`__

From tdelaney at avaya.com  Tue Jul  5 01:03:29 2005
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Tue, 5 Jul 2005 09:03:29 +1000
Subject: [Python-Dev] Terminology for PEP 343
Message-ID: <2773CAC687FD5F4689F526998C7E4E5F05CB19@au3010avexu1.global.avaya.com>

Phillip J. Eby wrote:

> Expand your mind.  :) "Resource" can include whatever objects you
> want it 
> to -- or no objects at all.  A resource can be conceptual - like for
> example the user's attention, or the contents of a status bar or log
> message, or the timing/profiling of an activity.  I think maybe you're

Well, HR considers me to be a resource ... ;)

Personally, I'm very happy with considering anything a with statement
manages as a resource.

Tim Delaney

From aahz at pythoncraft.com  Tue Jul  5 01:53:11 2005
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 4 Jul 2005 16:53:11 -0700
Subject: [Python-Dev] python-dev Summary for 2005-06-16 through
	2005-06-30 [draft]
In-Reply-To: <d11dcfba0507041435603983d4@mail.gmail.com>
References: <d11dcfba0507041435603983d4@mail.gmail.com>
Message-ID: <20050704235311.GA4553@panix.com>

Nothing to say, just keep up the good work!  I hope the triple-team
approach is still working well.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From nyamatongwe at gmail.com  Tue Jul  5 06:40:22 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Tue, 5 Jul 2005 14:40:22 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <7jg6csa2.fsf@python.net>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com> <r7ej9g91.fsf@python.net>
	<50862ebd050701190823dde486@mail.gmail.com> <7jg6csa2.fsf@python.net>
Message-ID: <50862ebd05070421404463c578@mail.gmail.com>

Thomas Heller:

> Not only that, all the other flags like -O and -E are also in sys.argvu
> but not in sys.argv.

   OK, new patch fixes these and the "-c" issue.

> Those are nearly obsoleted by the subprocess module (although I do not
> know how that handles unicode.

   It breaks. The argspec is zzOOiiOzO:CreateProcess.

>>> z = subprocess.Popen(u"cmd /c echo \u0417")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\zed\python\dist\src\lib\subprocess.py", line 600, in __init__
    errread, errwrite)
  File "c:\zed\python\dist\src\lib\subprocess.py", line 791, in _execute_child
    startupinfo)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0417' in
position 12: ordinal not in range(128)

   Neil

From greg.ewing at canterbury.ac.nz  Tue Jul  5 08:57:30 2005
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 05 Jul 2005 18:57:30 +1200
Subject: [Python-Dev] Terminology for PEP 343
References: <000301c5804b$3f001640$5f21cb97@oemcomputer>
	<2mk6k7vx5f.fsf@starship.python.net>
Message-ID: <42CA2F5A.7080603@canterbury.ac.nz>

Michael Hudson wrote:

> (I think Raymond has identified the problem I have with resource
> manager more clearly then I did; I certainly don't think I'd realise
> what "decimal.Context() is a resource manager" meant at first
> reading).

I'm also worried that "resource manager" is too narrow
a term, and would only fit by considerable stretching
in many cases.

I'm thinking about something like "context manager",
or at least something with "context" in it.

Greg


From greg.ewing at canterbury.ac.nz  Tue Jul  5 09:01:00 2005
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 05 Jul 2005 19:01:00 +1200
Subject: [Python-Dev] Terminology for PEP 343
References: <5.1.1.6.0.20050703220312.0272a948@mail.telecommunity.com>
	<5.1.1.6.0.20050704122534.02702e18@mail.telecommunity.com>
Message-ID: <42CA302C.9080904@canterbury.ac.nz>

Phillip J. Eby wrote:
> At 11:48 PM 7/3/2005 -0400, Raymond Hettinger wrote:

> with context_expression as variable:
>      # perform actions within a context
> 
> The "with" statement establishes a context in which some operations are to 
> be performed.

I like this.

> The object produced by 'context_expression' must have __enter_context__ and 
> __exit_context__ methods, which will be invoked by the "with" statement 
> when the context is entered...

And we could call this the "context protocol".

Greg




From ncoghlan at gmail.com  Tue Jul  5 15:04:05 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 05 Jul 2005 23:04:05 +1000
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <001501c580a2$9a75dd00$5f21cb97@oemcomputer>
References: <001501c580a2$9a75dd00$5f21cb97@oemcomputer>
Message-ID: <42CA8545.1050208@gmail.com>

Raymond Hettinger wrote:
>>"""
>>With Statements and Suite Management
> 
> 
> 
> This is nicely done :-)
> 
> Nit:  Replace "e.g." with "such as".
> 
> BTW, do you support changing __exit__ to __leave__?  I think it provides
> a small but useful gain in usability.

I was initially -0 on the idea, and I've moved to a solid -1 after 
spending more time thinking about it.

The only real pro I can see for 'leave' is that it is more common than 
'exit' in conversational English, particularly when using the past 
tense. However, I've come to see significant pros for staying with 'exit':

1. 'Exit' is more precise than 'leave'. 'exit' has just the one real 
meaning - to go out of something. It has a couple of variants on the 
theme, and can be used as both a verb and a noun, but the basic 
meaning stays the same. However, the same cannot be said for 'leave'. 
In addition to its usage as a synonym for 'exit', it can be used in 
the sense of not taking something ('leave it behind'), not doing 
something ('leave the lights on') or handing over responsibility 
('leave it to me'). When used as a noun, it refers to permission ('you 
have my leave') and absences ('annual leave').
'Exit' covers just what we mean, while 'leave' covers that and a hell 
of a lot more, leading me to favour 'exit' as the more precise term.

2. Enter/exit and arrive/leave are the natural terminology pairings in 
English. The first pair are more specific, implying the existence of 
an 'inside' and an 'outside', while the latter pair are significantly 
less fussy (e.g. consider arriving at and leaving a picnic in the 
park, versus trying to enter and exit that same picnic). It is just a 
quirk of the language that the more general term 'leave' is 
substituted for many uses of 'exit' (particularly when the past tense 
is involved). I suspect the single syllable of 'left' tends to win out 
over the three syllable verbal gymnastics of 'exited' (try saying the 
two words out loud - I found the difference to be surprising, and 
significantly more marked than the difference between 'enter' and 
'arrive').
In our case, code is written and read far more often than it is 
spoken, again leading me to favour the use of 'exit', this time as the 
more natural counterpart to 'enter'.

3. The common starting letter gives a nice visual pairing for 
enter/exit. This is not the case for enter/leave, again leading to a 
preference for the use of 'exit'.

Using 'leave' instead of 'exit' is an interesting idea, but I think 
these are good reasons to stick with the PEP 343 terminology.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From ncoghlan at gmail.com  Tue Jul  5 15:09:47 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 05 Jul 2005 23:09:47 +1000
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <000301c580c4$8da6ee80$e129cb97@oemcomputer>
References: <000301c580c4$8da6ee80$e129cb97@oemcomputer>
Message-ID: <42CA869B.9000804@gmail.com>

Raymond Hettinger wrote:
> This is much improved.  I think we're getting close. So far, I like
>  Nick's most recent version the best, but this is in the ballpark.

I like some of Phillip's suggestions, particularly the 'context' term. 
I'll put some thought into combining the two over the next couple of 
days. I spent too much time today thinking about the differences 
between exit and leave ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From fdrake at acm.org  Tue Jul  5 17:46:04 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue, 5 Jul 2005 11:46:04 -0400
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <42CA2F5A.7080603@canterbury.ac.nz>
References: <000301c5804b$3f001640$5f21cb97@oemcomputer>
	<2mk6k7vx5f.fsf@starship.python.net>
	<42CA2F5A.7080603@canterbury.ac.nz>
Message-ID: <200507051146.05430.fdrake@acm.org>

On Tuesday 05 July 2005 02:57, Greg Ewing wrote:
 > I'm thinking about something like "context manager",
 > or at least something with "context" in it.

Oh, I like this one.  "Context manager" / "context protocol" work well for me.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From ajsiegel at optonline.net  Tue Jul  5 16:17:09 2005
From: ajsiegel at optonline.net (Arthur)
Date: Tue, 05 Jul 2005 10:17:09 -0400
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API for
 sets.Set and build-in set)
Message-ID: <42CA9665.2090006@optonline.com>

>* and because Guido believes beginners tend to copy too much
>  (that is one reason why copy.copy is not a builtin) and that
>  the language should encourage correct behavior.


OTOH, beginners tend to copy not enough - when for example iterating over a list being acting upon.

Though my real argument for list.copy() as an aid to beginners is otherwise - a bit more obtuse/non-linear than that - 
so much so that it doesn't get much sympahty.  

It isn't realistic to expect beginners to pick up idioms near the outset of the learning process.
Now, copying lists is not something the beginner will often want to do, and the argument that once
they want to do so, they will also be comfortable with slicing and with more idiomatic Python is 
not an unreasonable argument.

But I believe it misses something more fundamental. It is a belief that is extracted from my own
experience in tackling Python as a first language - as an adult, being able - I think - to introspect
a bit better as to the process than I could if I were doing so at a younger age, and more in the
normal course.

The downside of Guido hiding "copy" to the extent it is - by not having a list.copy(), by not having
copy.copy as a built-in, by even rejecting the notion of a short blurb of the copy module in the
tutorial - is that the confrontation with the distinction between copying and "=" assignment gets delayed
and confusion on the point becomes frustrating - fundamentally so.

It doens't seem to me that this is an outlandish notion by any means. It can't be - as I seemed
to have experienced it.

Guido called this "one of my favorite subjects" in my last go around here on this issue.

Well, it is indeed an opinion I hold. Not of earthshaking importance.  But I hold it
firmly enough, nonetheless.  My flexiblity is more on the issue as to the extent that Python should
design itself around the needs of beginners. If the conclusion is that list.copy() is a distraction
to the experienced programmer, and that the motivated beginner will get to where they need to get,
in any case, with or without it - I'm on board.  

If the thought is that hiding "copy", or relying on idioms for a construct as fundamental as the list -
is a favor to the beginner, I very much am not.

Art


From jepler at unpythonic.net  Tue Jul  5 20:34:47 2005
From: jepler at unpythonic.net (Jeff Epler)
Date: Tue, 5 Jul 2005 13:34:47 -0500
Subject: [Python-Dev] getch() in msvcrt does not accept extended
	characters.
In-Reply-To: <1120081396.14913.13.camel@unixadmindazfc2.chh.co.nz>
References: <1120081396.14913.13.camel@unixadmindazfc2.chh.co.nz>
Message-ID: <20050705183446.GB19195@unpythonic.net>

Whatever it is that you need 'getch' to do, can't you incorporate it
first in an extension module you bundle with your application or
library, rather than using the (broken?) wrapper in the msvcrt module?

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20050705/48e5875c/attachment.pgp

From martin at v.loewis.de  Tue Jul  5 22:39:06 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 05 Jul 2005 22:39:06 +0200
Subject: [Python-Dev] using pyhon from the MSYS shell
In-Reply-To: <20050629133215.GB8241@panix.com>
References: <BAY22-F5D1E1FC04146C8B11A68EFFE10@phx.gbl>
	<20050629133215.GB8241@panix.com>
Message-ID: <42CAEFEA.50709@v.loewis.de>

Aahz wrote:
>>I was trying to compile a python plugin (for gimp) using the MSYS
>>shell and the MINGW compiler.
> 
> 
> python-dev is the wrong place for this question

Actually, it isn't - he is really asking what the best way of
porting Python to MSYS is.

Regards,
Martin

From martin at v.loewis.de  Tue Jul  5 22:46:35 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 05 Jul 2005 22:46:35 +0200
Subject: [Python-Dev] using pyhon from the MSYS shell
In-Reply-To: <BAY22-F5D1E1FC04146C8B11A68EFFE10@phx.gbl>
References: <BAY22-F5D1E1FC04146C8B11A68EFFE10@phx.gbl>
Message-ID: <42CAF1AB.7040002@v.loewis.de>

lode leroy wrote:
> maybe someone could extend os.path to do this in the standard distribution:
> implement an msyspath.py, which calls ntpath for each function, and does a 
> replace at the end of the evaluation.

The chances are good that nobody else will work on this - so it is
likely that it is either you who are doing this, or nobody else. Then,
when you eventually come up with a patch, somebody will tell you that
you partially erred, and that it should have been done in a different
way. Still, I think this might be the only way to come to a solution
that gets integrated with Python.

I'm personally in favour of supporting "MSYS" as a target system.
If you want to do it, I'm willing to review patches, but I'm not
willing to do them myself, as I don't use MSYS.

If you believe that MSYS is a target system in a way similar to
mingw32, and to cygwin, I believe it should get the same treatment
as mingw32 and cygwin. That means all places that currently deal
with either of these two systems should also deal with MSYS in
a similar way. What this means in actual code, I don't know.

OTOH, I already fail to follow you in the very first assumption:
why is it that you need to change os.sep on MSYS?

Regards,
Martin

From martin at v.loewis.de  Tue Jul  5 23:05:04 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 05 Jul 2005 23:05:04 +0200
Subject: [Python-Dev] Possible C API problem?
In-Reply-To: <20050627113152.071275.a25edf12@goombah.com>
References: <20050627113152.071275.a25edf12@goombah.com>
Message-ID: <42CAF600.7040302@v.loewis.de>

Gary Robinson wrote:
> #include <Python.h>
> static  double         gfSumChiSquare = 123.0; 
>             
> static PyObject *    
> getSumChiSquare(PyObject *self, PyObject *args){
>     return Py_BuildValue("d", gfSumChiSquare);
>     }
>     
> static PyMethodDef SimMethods[] = {
>     {"getSumChiSquare", getSumChiSquare, METH_NOARGS, "Return 
> fSumChiSquare"},
>     {NULL, NULL, 0, NULL}        /* Sentinel */
> };
> 
> PyMODINIT_FUNC
> inittestfloat(void)
> {
>     (void) Py_InitModule("testfloat", SimMethods);
> }

> Could it be that this is a python bug? Or am I doing something wrong?

You are doing something wrong. As getSumChiSquare is a METH_NOARGS
method, it shouldn't have a PyObject*args argument.

However, python-dev really isn't the place to get urgent help if
"there is intense time pressure to get the next release of our product
(http://www.goombah.com) ready". Instead, if you need help in this
case, you should hire somebody.

Regards,
Martin

From tjreedy at udel.edu  Tue Jul  5 23:42:23 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 5 Jul 2005 17:42:23 -0400
Subject: [Python-Dev] getch() in msvcrt does not accept extended
	characters.
References: <1120081396.14913.13.camel@unixadmindazfc2.chh.co.nz>
Message-ID: <daeus0$b0j$1@sea.gmane.org>


"Darryl Dixon" <esrever_otua at pythonhacker.is-a-geek.net> wrote in message 
news:1120081396.14913.13.camel at unixadmindazfc2.chh.co.nz...
>    I'm sorry, I don't seem to have done a very good job at explaining
> the situation.  I'll try again:

Actually, I think you did fine the first time, and the second time, and I 
see nothing new here.  You, like thousands of others (including Guido 
himself), want at least one little bit of Python to be different.

But you seem more persistent in ignoring responses and not takinge 'no' for 
an answer.  So I suggest that you reread previous responses more carefully, 
and/or take your complaint to comp.lang.python.

> 'getch()' is a low-level function provided on Windows to capture a
> single character of input from a user, /without echoing it to the
> screen/.  As far as I can tell there's no other way of doing this with
> Python on Windows.  The Python interface to this function is in the C
> code in msvcrtmodule.c, which has a (very thin) wrapper around the raw
> OS system call.

How many people have to say how many times that the thinness is 
intentional.  The module was added some years ago to make life easier for 
Windows programmers to wanted to use the calls they were familiar with in 
the way they were familiar with, even though it makes their programs 
non-portable.

>  Microsoft provide a way of accepting both normal ASCII
> codes, and extended characters via this system call.

According to you, Microsoft requires two calls.  Quoting you:

>>> Microsoft support capturing extended characters via _getch,
>>> but it requires making a second call to getch() if one of the
>>> 'magic' returns is encountered in the first call (0x00 or 0xE0).

You seem to be complaining that Python mimics Microsoft too well.

>  Currently, the
> Python wrapper in msvcrtmodule.c only supports the semantics of getting
> the bare ASCII codes, and not the extended characters.

Based on the source code and your posts, the Python sematics is the same as 
the MS semantics with 'Python char' (string of length 1) substituted for 'C 
char'.  So it seems untrue that Microsoft supports something Python does 
not and I am baffled why you keep saying so.

If making a second call from Python somehow acts differently than making a 
second call from C, then you *have* failed to demonstrate or explain 
*that*, and that seems to me like itmight be a legitimate reason to 
complain.

Terry J. Reedy




From grobinson at goombah.com  Tue Jul  5 23:52:31 2005
From: grobinson at goombah.com (Gary Robinson)
Date: Tue, 5 Jul 2005 17:52:31 -0400
Subject: [Python-Dev] Possible C API problem?
In-Reply-To: <42CAF600.7040302@v.loewis.de>
References: <20050627113152.071275.a25edf12@goombah.com>
	<42CAF600.7040302@v.loewis.de>
Message-ID: <20050705175231.968428.e6ce7f25@goombah.com>

> You are doing something wrong. As getSumChiSquare is a METH_NOARGS
> method, it shouldn't have a PyObject*args argument.

While I am aware enough of your general expertise to be surprised if 
you were in error in your statement below about VAR_NOARGS, your 
statement obove does seem to contradict the docs:

METH_VARARGS
 This is the typical calling convention, where the methods have the  
type PyCFunction. The function expects two  PyObject* values. The first 
one is the self object for  methods; for module functions, it has the 
value given to  Py_InitModule4() (or NULL if  Py_InitModule() was 
used). The second parameter  (often called args) is a tuple object 
representing all  arguments. This parameter is typically processed 
using PyArg_ParseTuple() or PyArg_UnpackTuple.

...

 METH_NOARGS
 Methods without parameters don't need to check whether arguments are  
given if they are listed with the METH_NOARGS flag. They  need to be of 
type PyCFunction. When used with object  methods, the first parameter 
is typically named self and will  hold a reference to the object 
instance. In all cases the second parameter will be NULL.

----

(http://python.fyxm.net/doc/2.3.5/api/common-structs.html#l2h-832

In other words the docs seem to explicitly state that the args will be 
supplied and what they will contain, so I'd assume that the C method 
should have them in their declaration. Moreover, METH_NOARGS needs to 
correspond to type PyCFunction, and the definition of type PyCFunction 
states that it must receive two args of PyObject*.

Are the docs wrong or am I misreading them? Or are you wrong?

Re your other comments, as mentioned in my personal email, the word 
done by folks in a couple of python forums in running tests does seem 
to confirm that there is some kind of bug involving gcc 3.3. The bus 
error appears independently of whether VAR_METHARGS or VAR_VARARGS is 
used. Also, (again as mentioned in my personal email) I do have 4 F/T 
experienced people working on this project, none of whom has the 
expertise to resolve this. Given that it looks like a real bug was 
uncovered, I think it was appropriate to post on the python forums 
about this. I only posted to python-dev because it was suggested that I 
do so by someone on the C++ sig.

Gary



-- 

Gary Robinson
CTO
Emergent Music, LLC
grobinson at goombah.com
207-942-3463
Company: http://www.goombah.com
Blog:    http://www.garyrobinson.net


From esrever_otua at pythonhacker.is-a-geek.net  Tue Jul  5 23:58:07 2005
From: esrever_otua at pythonhacker.is-a-geek.net (Darryl Dixon)
Date: Wed, 06 Jul 2005 09:58:07 +1200
Subject: [Python-Dev] getch() in msvcrt does not accept
	extended	characters.
In-Reply-To: <1120081396.14913.13.camel@unixadmindazfc2.chh.co.nz>
References: <1120081396.14913.13.camel@unixadmindazfc2.chh.co.nz>
Message-ID: <1120600688.11341.18.camel@unixadmindazfc2.chh.co.nz>

Sorry all,

    It seems that the list mods have finally released a duplicate
message that I wrote last week when I wasn't subscribed to the list.
Please ignore the message below if you have read the previous copy
already.

D


On Thu, 2005-06-30 at 09:43 +1200, Darryl Dixon wrote:
> Hi,
> 
>     I'm sorry, I don't seem to have done a very good job at explaining
> the situation.  I'll try again:
> 'getch()' is a low-level function provided on Windows to capture a
> single character of input from a user, /without echoing it to the
> screen/.  As far as I can tell there's no other way of doing this with
> Python on Windows.  The Python interface to this function is in the C
> code in msvcrtmodule.c, which has a (very thin) wrapper around the raw
> OS system call.  Microsoft provide a way of accepting both normal ASCII
> codes, and extended characters via this system call.  Currently, the
> Python wrapper in msvcrtmodule.c only supports the semantics of getting
> the bare ASCII codes, and not the extended characters.  I would strongly
> suggest that it should support both.
> 
> So, I guess in answer to the questions raised below;
> 
> 1) I can't do it in Python code without getch() (hence the original
> email)
> 
> 2) I would argue that in fact getch() is 'broken' in its current Python
> implementation, as it doesn't support what the OS implies /should/ be
> supported (and, indeed, if I input an extended character in response to
> a 'getch()' call, all I get back currently is an empty string).
> 
> Hope this helps,
> D
> 
> 
> Fredrik wrote:
> >Darryl Dixon wrote:
> >
> >> Microsoft support capturing extended characters via _getch, but it requires making a
> >> second call to getch() if one of the 'magic' returns is encountered in the first call (0x00
> >> or 0xE0).
> >
> >so why not do that in your python code?
> >
> >> The relevant chunk of code in Python that would probably need to be
> >> changed to support this appears to be in msvcrtmodule.c:
> >
> >if you change msvcrt, you'll break all the programs that uses getch() in
> >the prescribed way...
> >
> ></F> 
-- 
Darryl Dixon <esrever_otua at pythonhacker.is-a-geek.net>


From aahz at pythoncraft.com  Wed Jul  6 00:13:32 2005
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 5 Jul 2005 15:13:32 -0700
Subject: [Python-Dev] using pyhon from the MSYS shell
In-Reply-To: <42CAEFEA.50709@v.loewis.de>
References: <BAY22-F5D1E1FC04146C8B11A68EFFE10@phx.gbl>
	<20050629133215.GB8241@panix.com> <42CAEFEA.50709@v.loewis.de>
Message-ID: <20050705221332.GA3307@panix.com>

On Tue, Jul 05, 2005, "Martin v. L?wis" wrote:
> Aahz wrote:
>>Martin removed the attribution here:
>>>
>>>I was trying to compile a python plugin (for gimp) using the MSYS
>>>shell and the MINGW compiler.
>> 
>> python-dev is the wrong place for this question
> 
> Actually, it isn't - he is really asking what the best way of
> porting Python to MSYS is.

Hrm.  I thought we told people to start with comp.lang.python for
porting questions, but I'm happy to be corrected.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From martin at v.loewis.de  Wed Jul  6 01:02:01 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Jul 2005 01:02:01 +0200
Subject: [Python-Dev] Possible C API problem?
In-Reply-To: <20050705175231.968428.e6ce7f25@goombah.com>
References: <20050627113152.071275.a25edf12@goombah.com>
	<42CAF600.7040302@v.loewis.de>
	<20050705175231.968428.e6ce7f25@goombah.com>
Message-ID: <42CB1169.8070403@v.loewis.de>

Gary Robinson wrote:
> Are the docs wrong or am I misreading them? Or are you wrong?

It turns out that I am wrong. The NOARGS functions are indeed called
with an additional NULL argument; it's just that many functions with
NOARGS in Python itself are declared without the additional argument.

Regards,
Martin

From martin at v.loewis.de  Wed Jul  6 01:08:40 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Jul 2005 01:08:40 +0200
Subject: [Python-Dev] using pyhon from the MSYS shell
In-Reply-To: <20050705221332.GA3307@panix.com>
References: <BAY22-F5D1E1FC04146C8B11A68EFFE10@phx.gbl>	<20050629133215.GB8241@panix.com>
	<42CAEFEA.50709@v.loewis.de> <20050705221332.GA3307@panix.com>
Message-ID: <42CB12F8.9070406@v.loewis.de>

Aahz wrote:
> Hrm.  I thought we told people to start with comp.lang.python for
> porting questions, but I'm happy to be corrected.

I'm unaware of such a policy, but I may have missed the relevant
discussion. I could understand that questions of the kind "I tried
to build Python on X, and the compiler gave me the error message
Y" are for comp.lang.python - these messages are really the of the
"I need help" kind.

The specific message was more of the "I would like to change
code fragment X to Y to make it work on platform Z" kind - although
in the end, he still indicated that he appreciated help.

Oh well,

Martin

From greg.ewing at canterbury.ac.nz  Wed Jul  6 03:58:47 2005
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 06 Jul 2005 13:58:47 +1200
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API for
 sets.Set and build-in set)
In-Reply-To: <42CA9665.2090006@optonline.com>
References: <42CA9665.2090006@optonline.com>
Message-ID: <42CB3AD7.5020006@canterbury.ac.nz>

Arthur wrote:

> If the thought is that hiding "copy", or relying on idioms for a 
 > construct as fundamental as the list - is a favor to the beginner,
 > I very much am not.

I don't think anyone believes that. It's more a feeling that
Python shouldn't be cluttered up with things that are *only*
for beginners.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From greg.ewing at canterbury.ac.nz  Wed Jul  6 04:06:48 2005
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 06 Jul 2005 14:06:48 +1200
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <200507051146.05430.fdrake@acm.org>
References: <000301c5804b$3f001640$5f21cb97@oemcomputer>
	<2mk6k7vx5f.fsf@starship.python.net>
	<42CA2F5A.7080603@canterbury.ac.nz>
	<200507051146.05430.fdrake@acm.org>
Message-ID: <42CB3CB8.70409@canterbury.ac.nz>

Fred L. Drake, Jr. wrote:

> Oh, I like this one.  "Context manager" / "context protocol" work well for me.

And it means we get to say "decimal.context supports the context
protocol", which sounds perfectly sensible, even obvious. :-)

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From tjreedy at udel.edu  Wed Jul  6 04:11:41 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 5 Jul 2005 22:11:41 -0400
Subject: [Python-Dev] using pyhon from the MSYS shell
References: <BAY22-F5D1E1FC04146C8B11A68EFFE10@phx.gbl>	<20050629133215.GB8241@panix.com><42CAEFEA.50709@v.loewis.de>
	<20050705221332.GA3307@panix.com> <42CB12F8.9070406@v.loewis.de>
Message-ID: <dafeku$ckn$1@sea.gmane.org>


""Martin v. Löwis"" <martin at v.loewis.de> wrote in message 
news:42CB12F8.9070406 at v.loewis.de...
> Aahz wrote:
>> Hrm.  I thought we told people to start with comp.lang.python for
>> porting questions, but I'm happy to be corrected.
>
> I'm unaware of such a policy, but I may have missed the relevant
> discussion. I could understand that questions of the kind "I tried
> to build Python on X, and the compiler gave me the error message
> Y" are for comp.lang.python - these messages are really the of the
> "I need help" kind.

I had the same impression as Aahz: questions about how to use the existing 
distribution should go to c.l.p.  Besides keeping pydev clear, someone once 
claimed (as I remember) that there are many people with experience building 
Python on various systems that read c.l.p but not pydev.  (Still true? 
don't know!)

On the otherhand, once that fails and someone thinks the codebase needs 
more #ifdefs, then it does become a pydev matter.  And you saw right off 
that MSYS support might need just that.

tjr




From kbk at shore.net  Wed Jul  6 05:08:55 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Tue, 5 Jul 2005 23:08:55 -0400 (EDT)
Subject: [Python-Dev] Weekly Python Patch/Bug Summary
Message-ID: <200507060308.j6638t9Y014186@bayview.thirdcreek.com>

Patch / Bug Summary
___________________

Patches :  348 open ( +4) /  2879 closed ( +4) /  3227 total ( +8)
Bugs    :  898 open ( +1) /  5103 closed ( +9) /  6001 total (+10)
RFE     :  193 open ( +2) /   170 closed ( +0) /   363 total ( +2)

New / Reopened Patches
______________________

tarfile.py: ExFileObject's tell() is wrong after readline()  (2005-06-30)
       http://python.org/sf/1230446  opened by  Lars Gust?bel

Patch for (Doc) #1168746  (2005-06-30)
CLOSED http://python.org/sf/1230615  opened by  Peter van Kampen

Patch for (Doc) #1162912  (2005-07-03)
CLOSED http://python.org/sf/1231890  opened by  Peter van Kampen

audioop - alaw encoding/decoding added, code updated  (2005-07-01)
       http://python.org/sf/1231053  opened by  Lars Immisch

Add unicode for sys.argv, os.environ, os.system  (2005-07-02)
       http://python.org/sf/1231336  opened by  Neil Hodgson

Typo fix in compiler/transformer.py (WalkerEror)  (2005-07-02)
CLOSED http://python.org/sf/1231538  opened by  Adrien Di Mascio

MS Windows - module search path fix  (2005-07-04)
       http://python.org/sf/1232023  opened by  K. Thananchayan

PyOS_Readline  (2005-07-04)
       http://python.org/sf/1232343  opened by  Lisandro Dalcin

Patches Closed
______________

Patch for (Doc) #1168746  (2005-06-30)
       http://python.org/sf/1230615  closed by  birkenfeld

Patch for (Doc) #1162912  (2005-07-03)
       http://python.org/sf/1231890  closed by  birkenfeld

Patch for (Doc) bug #1228904  (2005-06-29)
       http://python.org/sf/1229935  closed by  birkenfeld

Typo fix in compiler/transformer.py (WalkerEror)  (2005-07-02)
       http://python.org/sf/1231538  closed by  birkenfeld

New / Reopened Bugs
___________________

Build failure  (2005-06-30)
       http://python.org/sf/1230161  opened by  L.M

tokenize bug  (2005-06-30)
       http://python.org/sf/1230484  opened by  Eduardo Aguiar

sys.excepthook doesn't work in threads  (2005-06-30)
       http://python.org/sf/1230540  opened by  Jonathan Ellis

decimal module is no longer 2.3 compatible  (2005-06-30)
CLOSED http://python.org/sf/1230553  opened by  Mike Orr

ioctl has problem with -ive request codes  (2005-07-01)
       http://python.org/sf/1231069  opened by  Barry Alan Scott

chr() returns ? when input > 127 in OS X  (2005-07-02)
       http://python.org/sf/1231488  opened by  Craig Howard

typesseq-mutable lacks note on combined key/cmp usage  (2005-03-14)
CLOSED http://python.org/sf/1162912  reopened by  birkenfeld

OverflowError in time.utime() causes strange traceback  (2005-07-04)
CLOSED http://python.org/sf/1232517  opened by  Joe Peterson

Mistakes in online docs under "5.3 Pure Embedding"  (2005-07-05)
       http://python.org/sf/1232768  opened by  Matt Smart

non-admin install may fail (win xp pro)  (2005-07-05)
       http://python.org/sf/1232947  opened by  pvrijlandt

openssl-0.9.8 requires _ssl.mak change  (2005-07-05)
       http://python.org/sf/1233049  opened by  Alan Meyer

Bugs Closed
___________

Two requests to one file are not done in parallel  (2005-06-25)
       http://python.org/sf/1227480  closed by  jafo

usage of type "char*" instead of "const char*"  (2005-06-27)
       http://python.org/sf/1228053  closed by  tjreedy

decimal module is no longer 2.3 compatible  (2005-06-30)
       http://python.org/sf/1230553  closed by  rhettinger

frame.f_exc_type,value,traceback  (2005-03-23)
       http://python.org/sf/1168746  closed by  birkenfeld

__getattribute__ documentation error?  (2005-05-19)
       http://python.org/sf/1204734  closed by  birkenfeld

weakref example broken  (2005-06-28)
       http://python.org/sf/1228904  closed by  birkenfeld

typesseq-mutable lacks note on combined key/cmp usage  (2005-03-14)
       http://python.org/sf/1162912  closed by  birkenfeld

typesseq-mutable lacks note on combined key/cmp usage  (2005-03-14)
       http://python.org/sf/1162912  closed by  birkenfeld

random.py/os.urandom robustness  (2005-04-06)
       http://python.org/sf/1177468  closed by  birkenfeld

OverflowError in time.utime() causes strange traceback  (2005-07-05)
       http://python.org/sf/1232517  closed by  mwh

New / Reopened RFE
__________________

platform.processor() could be smarter  (2005-07-01)
       http://python.org/sf/1231081  opened by  Stephan Springer

Links to tutorials and howtos from references  (2005-07-04)
       http://python.org/sf/1232073  opened by  Michael Hoffman


From adurdin at gmail.com  Wed Jul  6 06:16:59 2005
From: adurdin at gmail.com (Andrew Durdin)
Date: Wed, 6 Jul 2005 14:16:59 +1000
Subject: [Python-Dev] Triple-quoted strings and indentation
Message-ID: <59e9fd3a0507052116307e4d84@mail.gmail.com>

In general, I find triple-quoted strings to be very handy,
particularly for standalone scripts. However, the fact that they have
to be written in the left-hand column to avoid leading whitespace
really grates, particularly when they're nested within a block or two
-- it's a wart:

    try:
        options, args = getopt.getopt(sys.argv[1:], "cf:s")
    except getopt.GetoptError:
        print """Usage: dostuff <options>

Options:
  -c  - blah blah
  -f <filename>  - do stuff with file "filename"
  -s  - more blah"""

        sys.exit(1)

This really makes the code hard to read, as the indentation is all
mixed up (visually).

I have written a patch that changes the way triple-quoted strings are
scanned so that leading whitespace is ignored in much the same way
that pep 257 handles it for docstrings. Largely this was for a
learning experience in hacking the parser, but it would be very nice
IMO if something of this sort could be implemented in a future version
of Python. To this end, I have sketched out a draft PEP (which was
itself a good learning exercise in thinking out the issues of such a
change). Should I post it here for discussion?

Andrew

From steven.bethard at gmail.com  Wed Jul  6 06:29:22 2005
From: steven.bethard at gmail.com (Steven Bethard)
Date: Tue, 5 Jul 2005 22:29:22 -0600
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <59e9fd3a0507052116307e4d84@mail.gmail.com>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
Message-ID: <d11dcfba05070521296ac46091@mail.gmail.com>

On 7/5/05, Andrew Durdin <adurdin at gmail.com> wrote:
>         print """Usage: dostuff <options>
> 
> Options:
>   -c  - blah blah
>   -f <filename>  - do stuff with file "filename"
>   -s  - more blah"""

Isn't the standard idiom for this already:

import textwrap
...
    print textwrap.dedent("""\
        Usage: dostuff <options>

        Options:
         -c  - blah blah
         -f <filename>  - do stuff with file "filename"
         -s  - more blah""")

STeVe
-- 
You can wordify anything if you just verb it.
        --- Bucky Katt, Get Fuzzy

From tjreedy at udel.edu  Wed Jul  6 07:36:01 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 6 Jul 2005 01:36:01 -0400
Subject: [Python-Dev] Triple-quoted strings and indentation
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
Message-ID: <dafqk2$211$1@sea.gmane.org>


"Andrew Durdin" <adurdin at gmail.com> wrote in message 
news:59e9fd3a0507052116307e4d84 at mail.gmail.com...
> In general, I find triple-quoted strings to be very handy,
> particularly for standalone scripts. However, the fact that they have
> to be written in the left-hand column to avoid leading whitespace
> really grates, particularly when they're nested within a block or two
> -- it's a wart:
>
>    try:
>        options, args = getopt.getopt(sys.argv[1:], "cf:s")
>    except getopt.GetoptError:
>        print """Usage: dostuff <options>
>
> Options:
>  -c  - blah blah
>  -f <filename>  - do stuff with file "filename"
>  -s  - more blah"""
>
>        sys.exit(1)
>
> This really makes the code hard to read, as the indentation is all
> mixed up (visually).
>
> I have written a patch that changes the way triple-quoted strings are
> scanned so that leading whitespace is ignored in much the same way
> that pep 257 handles it for docstrings. Largely this was for a
> learning experience in hacking the parser, but it would be very nice
> IMO if something of this sort could be implemented in a future version
> of Python. To this end, I have sketched out a draft PEP (which was
> itself a good learning exercise in thinking out the issues of such a
> change). Should I post it here for discussion?
>
> Andrew
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
> 




From tjreedy at udel.edu  Wed Jul  6 07:59:51 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 6 Jul 2005 01:59:51 -0400
Subject: [Python-Dev] Triple-quoted strings and indentation
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
Message-ID: <dafs0o$4fm$1@sea.gmane.org>


"Andrew Durdin" <adurdin at gmail.com> wrote in message 
news:59e9fd3a0507052116307e4d84 at mail.gmail.com...
> In general, I find triple-quoted strings to be very handy,
> particularly for standalone scripts. However, the fact that they have
> to be written in the left-hand column to avoid leading whitespace
> really grates, particularly when they're nested within a block or two

At present I think I would do
usage_text = '''\
text how I want it
'''
perhaps in global context or at top of function and then

>    try:
>        options, args = getopt.getopt(sys.argv[1:], "cf:s")
>    except getopt.GetoptError:
         print usage_text

I long ago found it advantageous to pull message texts from scattered 
locations into a central place where easier to find and edit.  I also make 
program logic easier to read without a long block in the way.  YMMV
Doc strings, first meant for the code reader, need to be where they are.
They also come before the code itself, so don't interfere.

> -- it's a wart:

That is rather extreme, and is definitely an opinion.

> I have written a patch that changes the way triple-quoted strings are
> scanned so that leading whitespace is ignored.

And what if I want the leading whitespace left just the way I carefully put 
it?  And what of existing code dependent on literals being as literal as 
they currently are?  I think the soonest this could be considered is Python 
3.0.

Terry J. Reedy





From Michaels at rd.bbc.co.uk  Wed Jul  6 10:12:58 2005
From: Michaels at rd.bbc.co.uk (Michael Sparks)
Date: Wed, 6 Jul 2005 09:12:58 +0100
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <5.1.1.6.0.20050703220312.0272a948@mail.telecommunity.com>
References: <412c1fa419edec855bc719cacdba58e9@python.net>
	<5.1.1.6.0.20050703220312.0272a948@mail.telecommunity.com>
Message-ID: <200507060912.58977.Michaels@rd.bbc.co.uk>

On Monday 04 Jul 2005 03:10, Phillip J. Eby wrote:
> At 03:41 PM 7/3/2005 -0400, Raymond Hettinger wrote:
> >[Michael Hudson]
> > > This is possible.  I just wanted to expand everyone's minds :)
> > The mechanism is more general than resourcemanagement.  
> Expand your mind.  :) "Resource" can include whatever objects you want it
> to -- or no objects at all.

Is printing HTML and guaranteeing ending tags a resource ? I've been reading 
this thread, and been thinking that Holger Kregel's XPython hack could be 
implemented using the new with statement.

with some_encoding:
   with html:
      with body:
         with h1:
            print "Some heading"
         with p:
            print "This is paragraph 1"
         with p:
            print "This is paragraph 2"
         with h2:
            print "Another heading"

The enter/exit for html would be to print <html> </html> respectively and so 
on. (Though "p" would be special cased, etc)

Personally it seems to me that "with" is more a form of *guarantee* -
something that has a guard to enter the block, and something that
does something after the block.

From that perspective you could even imagine:

with enforce_conditions(pre,post):
   do some work.
   ...
   ...

enforce_conditions
   - enforces the "pre" before entering the block, and may choose to throw an
     exception if the precondition is false.
   - checks that "post" holds after the block, and may throw an exception if
     the postcondition is false.

Again, I don't really see that as a resource type scenario. It *may* involve
a resource scenario, but it may not. (eg did a condition finish within a 
certain time?)

Perhaps calling it a guarantor? (or similar)
   * You can guarantee that you have the lock on a resource if you enter the
      block ?
   * You can guarantee that you will have properly form (X|HT)ML if using an
     appropriate approach ?
   * You can guarantee checking of post conditions in a uniform manner ?

(Assumption: That the word guarantee in this case matches that of the intent)

If you just call the with statement a "resource manager" I suspect that people 
will more /naturally/ think just along the idea of resources, rather than 
also along the lines of things that need guarantees.

Is that really a resource type scenario? 

Best Regards,


Michael.
-- 
Michael Sparks, Senior R&D Engineer, Digital Media Group
Michael.Sparks at rd.bbc.co.uk, http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This e-mail may contain personal views which are not the views of the BBC.

From adurdin at gmail.com  Wed Jul  6 11:36:51 2005
From: adurdin at gmail.com (Andrew Durdin)
Date: Wed, 6 Jul 2005 19:36:51 +1000
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <dafs0o$4fm$1@sea.gmane.org>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
	<dafs0o$4fm$1@sea.gmane.org>
Message-ID: <59e9fd3a0507060236cddc3ba@mail.gmail.com>

On 7/6/05, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> Doc strings, first meant for the code reader, need to be where they are.
> They also come before the code itself, so don't interfere.

Doc strings are really not an issue, due to the conventions for
processing whitespace in them (and also the fact that their primary
use is for the reader of the code, even before any automated
processing).
 
> > -- it's a wart:
> 
> That is rather extreme, and is definitely an opinion.

My opinion, certainly.  However, I think the fact that workarounds for
the leading whitespace issue are needed (PEP 257, textwrap.dedent("""\
<text begins on next line>)) points to it being more than that. But of
course that is also my opinion :-)

> And what if I want the leading whitespace left just the way I carefully put
> it?

You can still put leading whitespace as you want it -- there would
just be a slightly different convention to follow -- I'll post what I
wrote up so you can see the whole proposal: better than me repeating
it all in bits.

> And what of existing code dependent on literals being as literal as
> they currently are?

There would be some breakage, certainly -- though I believe it would
be quite little.

> I think the soonest this could be considered is Python
> 3.0.

Quite likely so.

Andrew

From adurdin at gmail.com  Wed Jul  6 11:45:52 2005
From: adurdin at gmail.com (Andrew Durdin)
Date: Wed, 6 Jul 2005 19:45:52 +1000
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <59e9fd3a0507060236cddc3ba@mail.gmail.com>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
	<dafs0o$4fm$1@sea.gmane.org>
	<59e9fd3a0507060236cddc3ba@mail.gmail.com>
Message-ID: <59e9fd3a05070602451125d803@mail.gmail.com>

Here's the draft PEP I wrote up:

Abstract

    Triple-quoted string (TQS henceforth) literals in Python preserve
    the formatting of the literal string including newlines and 
    whitespace.  When a programmer desires no leading whitespace for 
    the lines in a TQS, he must align all lines but the first in the 
    first column, which differs from the syntactic indentation when a 
    TQS occurs within an indented block.  This PEP addresses this 
    issue.


Motivation

    TQS's are generally used in two distinct manners: as multiline 
    text used by the program (typically command-line usage information 
    displayed to the user) and as docstrings.

    Here's a hypothetical but fairly typical example of a TQS as a 
    multiline string:
    
        if not interactive_mode:
            if not parse_command_line():
                print """usage: UTIL [OPTION] [FILE]...

        try `util -h' for more information."""
                sys.exit(1)

    Here the second line of the TQS begins in the first column, which 
    at a glance appears to occur after the close of both "if" blocks.
    This results in a discrepancy between how the code is parsed and 
    how the user initially sees it, forcing the user to jump the 
    mental hurdle in realising that the call to sys.exit() is actually 
    within the second "if" block.
    
    Docstrings on the other hand are usually indented to be more 
    readable, which causes them to have extraneous leading whitespace 
    on most lines.  To counteract the problem, PEP 257 [1] specifies a 
    standard algorithm for trimming this whitespace.
    
    In the end, the programmer is left with a dilemma: either to align 
    the lines of his TQS to the first column, and sacrifice readability;
    or to indent it to be readable, but have to deal with unwanted
    whitespace.

    This PEP proposes that TQS's should have a certain amount of 
    leading whitespace trimmed by the parser, thus avoiding the 
    drawbacks of the current behaviour.
   

Specification

    Leading whitespace in TQS's will be dealt with in a similar manner 
    to that proposed in PEP 257:
    
        "... strip a uniform amount of indentation from the second
        and further lines of the [string], equal to the minimum 
        indentation of all non-blank lines after the first line.  Any 
        indentation in the first line of the [string] (i.e., up to 
        the first newline) is insignificant and removed.  Relative 
        indentation of later lines in the [string] is retained."

    Note that a line within the TQS that is entirely blank or consists 
    only whitespace will not count toward the minimum indent, and will 
    be retained as a blank line (possibly with some trailing whitespace).
        
    There are several significant differences between this proposal and
    PEP 257's docstring parsing algorithm:
    
    *   This proposal considers all lines to end at the next newline in
        the source code (whether escaped or not); PEP 257's algorithm
        only considers lines to end at the next (necessarily unescaped)
        newline in the parsed string.
        
    *   Only literal whitespace is counted; an escape such as \x20 
        will not be counted as indentation.
        
    *   Tabs are not converted to spaces.

    *   Blank lines at the beginning and end of the TQS will *not* be 
        stripped.

    *   Leading whitespace on the first line is preserved, as is 
        trailing whitespace on all lines.


Rationale

    I considered several different ways of determining
    the amount of whitespace to be stripped, including:
    
    1.  Determined by the column (after allowing for expanded tabs) of 
        the triple-quote:
            
            myverylongvariablename = """\
                                         This line is indented,
                                     But this line is not.
                                     Note the trailing newline:
                                     """
        
        +   Easily allows all lines to be indented.
        
        -   Easily leads to problems due to re-alignment of all but 
            first line when mixed tabs and spaces are used.
        
        -   Forces programmers to use a particular level of 
            indentation for continuing TQS's.
        
        -   Unclear whether the lines should align with the triple-
            quote or immediately after it.

        -   Not backward compatible with most non-docstrings.

    2.  Determined by the indent level of the second line of the 

        string:
    
            myverylongvariablename = """\
                This line is not indented (and has no leading newline),
                    But this one is.
                Note the trailing newline:
                """
    
        +   Allows for flexible alignment of lines.
        
        +   Mixed tabs and spaces should be fine (as long as they're 
            consistent).
        
        -   Cannot support an indent on the second line of the 
            string (very bad!).
            
        -   Not backward compatible with most non-docstrings.
    
    3.  Determined by the minimum indent level of all lines after the 

        first:
        
            myverylongvariablename = """\
                    This line is indented,
                But this line is not.
                Note the trailing newline:
                """
    
        +   Allows for flexible alignment of lines.
        
        +   Mixed tabs and spaces should be fine (as long as they're 
            consistent).

        +   Backward compatible with all docstrings and a majority of 
            non-docstrings

        -   Support for indentation on all lines not immediately 
            obvious

    Overall, solution 3 provided the best balance of features, and 
    (importantly) had the best backward compatibility.  I thus
    consider it the most suitable.


Examples

    The examples here are set out in pairs: the first of each pair 
    shows how the TQS must be currently written to avoid indentation 
    issues; the second shows how it can be written using this proposal 
    (although some variation is possible).  All examples are taken or 
    adapted from the Python standard library or another real source.
    
    1.  Command-line usage information:

        def usage(outfile):
            outfile.write("""Usage: %s [OPTIONS] <file> [ARGS]

        Meta-options:
        --help                Display this help then exit.
        --version             Output version information then exit.
        """ % sys.argv[0])

        #------------------------#
        
        def usage(outfile):
            outfile.write("""Usage: %s [OPTIONS] <file> [ARGS]

                Meta-options:
                --help                Display this help then exit.
                --version             Output version information then exit.
                """ % sys.argv[0])

    2.  Embedded Python code:

        self.runcommand("""if 1:
        import sys as _sys
        _sys.path = %r
        del _sys
        \n""" % (sys.path,))

        #------------------------#

        self.runcommand("""\
            if 1:
                import sys as _sys
                _sys.path = %r
                del _sys
                \n""" % (sys.path,))

    3.  Unit testing
    
        class WrapTestCase(BaseTestCase):
            def test_subsequent_indent(self):
                # Test subsequent_indent parameter
                 expect = '''\
          * This paragraph will be filled, first
            without any indentation, and then
            with some (including a hanging
            indent).'''
                result = fill(self.text, 40,
                              initial_indent="  * ",
                              subsequent_indent="    ")
                self.check(result, expect)

        #------------------------#
     
        class WrapTestCase(BaseTestCase):
            def test_subsequent_indent(self):
                # Test subsequent_indent parameter
                 expect = '''\
                      * This paragraph will be filled, first
                        without any indentation, and then
                        with some (including a hanging
                        indent).\
                    '''
                result = fill(self.text, 40,
                              initial_indent="  * ",
                              subsequent_indent="    ")
                self.check(result, expect)

     Example 3 illustrates how indentation of all lines (by 2 spaces) 
     is achieved with this proposal: the position of the closing 
     triple quote is used to determine the minimum indentation for the 
     whole string.  To avoid a trailing newline in the string, the 
     final newline is escaped.  Example 2 avoids the need for this 
     construction by placing the first line (which is not indented) on 
     the line after the triple-quote, and escaping the leading 
     newline.


Backwards Compatibility

    Uses of TQS's fall into two broad categories: those where 
    indentation is significant, and those where it is not.  Those in 
    the latter (larger) category, which includes all docstrings, will 
    remain effectively unchanged under this proposal.  Docstrings in 
    particular are usually trimmed according to the rules in PEP 257 
    before their value is used; the trimmed strings will be the same 
    under this proposal as they are now.
    
    Of the former category, the majority are those which have at least 
    one line beginning in the first column of the source code; these 
    will be entirely unaffected if left alone, but may be reformatted 
    to increase readability (see example 1 above).  However a small 
    number of strings in this first category depend on all lines (or 
    all but the first) being indented.  Under this proposal, these 
    will need to be edited to ensure that the intended amount of 
    whitespace is preserved.  Examples 2 and 3 above show two 
    different ways to reformat the strings for these cases.  Note that 
    in both examples, the overall indentation of the code is cleaner, 
    producing more readable code.
    
    Some evidence may be desired to support the claims made above 
    regarding the distribution of the different uses of TQS's.  I have 
    begun some analysis to produce some statistics for these; while 
    still incomplete, I have some initial results for the Python 2.4.1 
    standard library (these figures should not be off by more than a 
    small margin):
    
    In the standard library (some 396,598 lines of Python code), there 
    are 7,318 occurrences of TQS's, an average rate of one per 54 
    lines.  Of these, 6,638 (90.7%) are docstrings; the remaining 680 
    (9.3%) are not.  A further examination shows that 
    only 64 (0.9%) of these have leading indentation on all lines (the
    only case where the proposed solution is not backward compatible).
    These must be manually checked to determine 
    whether they will be affected; such a check reveals only 7-15 
    TQS's (0.1%-0.2%) that actually need to be edited.

    Although small, the impact of this proposal on compatibility is 
    still more than negligible; if accepted in principle, it might be 
    better suited to be initially implemented as a __future__ feature, 
    or perhaps relegated to Python 3000.
    

Implementation

    An implementation for this proposal has been made; however I have 
    not yet made a patch file with the changes, nor do the changes yet 
    extend to the documentation or other affected areas.


References

    [1] PEP 257, Docstring Conventions, David Goodger, Guido van Rossum
        http://www.python.org/peps/pep-0257.html


Copyright

    This document has been placed in the public domain.

From ncoghlan at gmail.com  Wed Jul  6 12:01:09 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 06 Jul 2005 20:01:09 +1000
Subject: [Python-Dev] Terminology for PEP 343
In-Reply-To: <200507060912.58977.Michaels@rd.bbc.co.uk>
References: <412c1fa419edec855bc719cacdba58e9@python.net>	<5.1.1.6.0.20050703220312.0272a948@mail.telecommunity.com>
	<200507060912.58977.Michaels@rd.bbc.co.uk>
Message-ID: <42CBABE5.90004@gmail.com>

Michael Sparks wrote:
> On Monday 04 Jul 2005 03:10, Phillip J. Eby wrote:
> 
>>At 03:41 PM 7/3/2005 -0400, Raymond Hettinger wrote:
>>
>>>[Michael Hudson]
>>>
>>>>This is possible.  I just wanted to expand everyone's minds :)
>>>
>>>The mechanism is more general than resourcemanagement.  
>>
>>Expand your mind.  :) "Resource" can include whatever objects you want it
>>to -- or no objects at all.
> 
> 
> Is printing HTML and guaranteeing ending tags a resource ? I've been reading 
> this thread, and been thinking that Holger Kregel's XPython hack could be 
> implemented using the new with statement.
> 
> with some_encoding:
>    with html:
>       with body:
>          with h1:
>             print "Some heading"
>          with p:
>             print "This is paragraph 1"
>          with p:
>             print "This is paragraph 2"
>          with h2:
>             print "Another heading"
> 
> The enter/exit for html would be to print <html> </html> respectively and so 
> on. (Though "p" would be special cased, etc)

Phillip's 'context' terminology, on the other hand, applies beautifully:

- encoding context
- HTML context
- HTML body context
- HTML heading 1 context
- HTML paragraph context

I think we have a winner. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From nyamatongwe at gmail.com  Wed Jul  6 13:11:26 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Wed, 6 Jul 2005 21:11:26 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <ca471dc205070400441ab49ffb@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
	<ca471dc2050703112845321ad3@mail.gmail.com>
	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
Message-ID: <50862ebd05070604117e9c5fb4@mail.gmail.com>

Guido van Rossum:

> Ah, sigh. I didn't know that os.listdir() behaves differently when the
> argument is Unicode. Does os.listdir(".") really behave differently
> than os.listdir(u".")? 

   Yes:
>>> os.listdir(".")
['abc', '????????????']
>>> os.listdir(u".")
[u'abc', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435']

> Bah! I don't think that's a very good design
> (although I see where it comes from). 

   Partly my fault. At the time I was more concerned with making
functionality possible rather than convenient.

> Promoting only those entries
> that need it seems the right solution -- user code that can't deal
> with the Unicode entries shouldn't be used around directories
> containing unicode -- if it needs to work around unicode it should be
> fixed to support that!

   OK, I'll work on a patch for that but I'd like to see the opinions
of the usual unicode guys as this will produce more opportunities for
UnicodeDecodeError. The modification will probably work in the
opposite way, asking for all the names in unicode and then attempting
to convert to the default code page with failures retaining the
unicode name.

   Neil

From ncoghlan at gmail.com  Wed Jul  6 13:12:18 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 06 Jul 2005 21:12:18 +1000
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42C91A07.9030402@gmail.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	<42C75006.6090902@ronadam.com>	<42C7E146.4090403@gmail.com>
	<42C91A07.9030402@gmail.com>
Message-ID: <42CBBC92.4040804@gmail.com>

OK, here's some draft documentation using Phillip's context 
terminology. I think it works very well.

"""
With Statements and Context Management

A frequent need in programming is to ensure a particular action is
taken after a specific section of code has been executed (such as 
closing a file or releasing a lock). The tool to achieve this in 
Python is to use the 'with' statement along with the appropriate 
context manager. Context managers ensure a particular action is taken 
to establish the context before the contained suite is entered, and a 
second action to clean up the context when the suite is exited.

The precise behaviour of the 'with' statement is governed by the
supplied context manager - an object which supports the context 
management protocol. This protocol consists of two methods:

     __enter__(self):
       Context managers use this method to create the desired context 
for the execution of the contained suite.
       This method is called without arguments before the contained
suite is entered. If the 'as' clause of the 'with' statement is used,
the value returned from this method is assigned to the identified target.
       Many context managers will return self from this method, but 
returning a different object may make sense for some managers (e.g. 
see the 'closing' suite manager example below).

     __exit__(self, exc_type, exc_value, exc_traceback):
       Context managers use this method to clean up after execution of 
the contained suite.
       This method is called after the contained suite has exited. If
the suite was left due to an exception, the details of that exception
are passed as arguments. Otherwise, all three arguments are set to None.
       If exception details are passed in, and this method returns
without incident, then the original exception continues to propagate.
Otherwise, the exception raised by this method will replace the
original exception.


Using Contexts to Manage Resources

The simplest use of context management is to strictly control the
handling of key resources (such as files, generators, database
connections, synchronisation locks).

These resource managers will generally acquire the resource in their
__enter__ method, although some resource managers may accept the
resource to be managed as an argument to the constructor or acquire it
during construction. Resource managers will then release the resource
in their __exit__ method.

Some resources (such as threading.Lock) support the context management
protocol natively, allowing them to be used directly in 'with' 
statements. The meaning of the established context will depend on the 
specific resource. In the case of threading.Lock, the lock is acquired 
by the __enter__ method, and released by the __exit__ method.


More Context Management Examples

While resource management may be the most obvious use of the context
management protocol, many more uses are possible (otherwise it would 
have been called the resource management protocol!).

For example, when used as a context manager, a decimal.Context object 
will set itself as the current Decimal arithmetic context in the 
__enter__ method, and then automatically revert back to the previous 
Deciaml arithmetic context in the __exit__ method. This allows the 
code in the contained suite to manipulate the Decimal arithmetic 
context freely, without needing to worry about manually undoing any 
changes.

Another example is the use of contexts to handle insertion of the 
appropriate tags when generating HTML:

    with html:
       with body:
          with h1:
             print "Some heading"
          with p:
             print "This is paragraph 1"
          with p:
             print "This is paragraph 2"
          with h2:
             print "Another heading"

Some other possibilities for context management include automatic 
exception logging and handling of database transactions.


Using Generators to Define Context Managers

In conjunction with the 'context' decorator, Python's
generators provide a convenient way to implement the context
management protocol, and share state between the __enter__ and
__exit__ methods.

The generator must yield exactly once during normal execution. The
context manager's __enter__ method executes the generator up to that
point, and the value yielded is returned. The remainder of the
generator is executed by the context manager's __exit__ method. Any
exceptions that occur in the managed context will be injected into the
generator at the location of the yield statement.

For example, the following context manager allows prompt closure of
any resource with a 'close' method (e.g. a generator or file):

     @context
     def closing(resource):
         try:
             yield resource
         finally:
             resource.close()

The operation of the context decorator is described by the following 
Python equivalent (although the exact error messages may differ):

     class ContextManager(object):
         def __init__(self, gen):
             self.gen = gen

         def __enter__(self):
             try:
                 return self.gen.next()
             except StopIteration:
                 raise RuntimeError("generator didn't yield")

         def __exit__(self, type, value, traceback):
             if type is None:
                 try:
                     self.gen.next()
                 except StopIteration:
                     return
                 else:
                     raise RuntimeError("generator didn't stop")
             else:
                 try:
                     self.gen.throw(type, value, traceback)
                 except (type, StopIteration):
                     return
                 else:
                     raise RuntimeError("generator didn't stop")

     def context(func):
         @wraps(func) # [1]
         def helper(*args, **kwds):
             return ContextManager(func(*args, **kwds))
         return helper
"""

[1] Is Python 2.5 going to include a standard decorator for building 
'well-behaved' wrapper functions?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From p.f.moore at gmail.com  Wed Jul  6 14:08:42 2005
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 6 Jul 2005 13:08:42 +0100
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
In-Reply-To: <42CBBC92.4040804@gmail.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>
	<42C91A07.9030402@gmail.com> <42CBBC92.4040804@gmail.com>
Message-ID: <79990c6b0507060508adf1f@mail.gmail.com>

On 7/6/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> OK, here's some draft documentation using Phillip's context
> terminology. I think it works very well.

I agree. +1 on this terminology, and for this explanation to be
included in the docs.

I also like the fact that it offers a neat 1-word name for the
generator decorator, "@context".

Paul.

From mcherm at mcherm.com  Wed Jul  6 14:20:26 2005
From: mcherm at mcherm.com (Michael Chermside)
Date: Wed, 06 Jul 2005 05:20:26 -0700
Subject: [Python-Dev] 'With' context documentation draft (was
	Re:	Terminology for PEP 343
Message-ID: <20050706052026.aerf6gnbp7k4kooo@login.werra.lunarpages.com>

Nick writes sample documentation:
> For example, the following context manager allows prompt closure of
> any resource with a 'close' method (e.g. a generator or file):
>
>      @context
>      def closing(resource):
>          try:
>              yield resource
>          finally:
>              resource.close()

Reading this I get the feeling that perhaps the decorator should
be named "context_manager" not "context":

        @context_manager
        def closing(resource):
            try:
                yield resource
            finally:
                resource.close()

Does anyone else agree?

Paul Moore writes:
> I also like the fact that it offers a neat 1-word name for the
> generator decorator, "@context".

Well, ok... does anyone *else* agree? I too saw this and thought "neat!
a simple one-word name!". But then I started worrying that it's not
defining the *context*, but rather the *context manager*. While
"context manager" is a term I could easily imagine associating only
with 'with' statements, "context" is too general a term... even after
Python supports 'with' statements I will continue to use "context"
to mean lots of different things (eg: decimal.context).

By the way, great job Nick... these docs read quite nicely.

-- Michael Chermside


From ncoghlan at gmail.com  Wed Jul  6 14:32:36 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 06 Jul 2005 22:32:36 +1000
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <59e9fd3a05070602451125d803@mail.gmail.com>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>	<dafs0o$4fm$1@sea.gmane.org>	<59e9fd3a0507060236cddc3ba@mail.gmail.com>
	<59e9fd3a05070602451125d803@mail.gmail.com>
Message-ID: <42CBCF64.1090106@gmail.com>

Andrew Durdin wrote:
> Here's the draft PEP I wrote up:

Well reasoned, and well written up IMO. In particular, being able to 
preserve all leading whitespace by the simple expedient of putting the 
closing triple quote in column zero and escaping the final newline is 
a nice feature.

However, while I prefer what you describe to Python's current 
behaviour, I am not yet convinced the backward compatibility pain is 
worth it. Adding yet-another-kind-of-string-literal (when we already 
have bytestrings on the horizon) is also unappealing.

Your readability examples are good, but the first two involve strings 
that should probably be module level constants (as Terry described) 
and the test case involving expected output is probably better handled 
using doctest, which has its own mechanism for handling indentation.

Raw and unicode string literals need to be mentioned in the PEP. Which 
literals would the reformatting apply to? All 3? Only standard and 
unicode, leaving raw strings alone?

You should research the reasons why PEP 295 [1] was rejected, and 
describe in the new PEP how it differs from PEP 295 (unfortunately PEP 
295 was not updated with the rationale for rejection, but this post 
[2] looks like Guido putting the final nail in its coffin).

Regards,
Nick.

[1] http://www.python.org/peps/pep-0295.html
[2] http://mail.python.org/pipermail/python-dev/2002-July/026969.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From mwh at python.net  Wed Jul  6 14:35:49 2005
From: mwh at python.net (Michael Hudson)
Date: Wed, 06 Jul 2005 13:35:49 +0100
Subject: [Python-Dev] Possible C API problem?
In-Reply-To: <42CB1169.8070403@v.loewis.de> (
	=?iso-8859-1?q?Martin_v._L=F6wis's_message_of?= "Wed,
	06 Jul 2005 01:02:01 +0200")
References: <20050627113152.071275.a25edf12@goombah.com>
	<42CAF600.7040302@v.loewis.de>
	<20050705175231.968428.e6ce7f25@goombah.com>
	<42CB1169.8070403@v.loewis.de>
Message-ID: <2m3bqsw1qy.fsf@starship.python.net>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> Gary Robinson wrote:
>> Are the docs wrong or am I misreading them? Or are you wrong?
>
> It turns out that I am wrong.

This is a long standing confusion.  At one point, the documentation
said what you said, and it was just as wrong.  There were even
inaccurate PyNoArgsCFunction typedefs in some header!

I think Python in a Nutshell is wrong here too.

> The NOARGS functions are indeed called with an additional NULL
> argument; it's just that many functions with NOARGS in Python itself
> are declared without the additional argument.

I've been fixing these when I find them, slowly.

Fortunately (and obviously, given the lack of bug reports) it won't
make any difference with any ABI I know about.

Cheers,
mwh

-- 
  I have gathered a posie of other men's flowers, and nothing but
  the thread that binds them is my own.                   -- Montaigne

From ncoghlan at gmail.com  Wed Jul  6 14:47:58 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 06 Jul 2005 22:47:58 +1000
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <79990c6b0507060508adf1f@mail.gmail.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>	
	<42C91A07.9030402@gmail.com> <42CBBC92.4040804@gmail.com>
	<79990c6b0507060508adf1f@mail.gmail.com>
Message-ID: <42CBD2FE.3000204@gmail.com>

Paul Moore wrote:
> On 7/6/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
>>OK, here's some draft documentation using Phillip's context
>>terminology. I think it works very well.
> 
> 
> I agree. +1 on this terminology, and for this explanation to be
> included in the docs.
> 
> I also like the fact that it offers a neat 1-word name for the
> generator decorator, "@context".

I liked that too, along with 'ContextManager' as the name for the 
controlling class that had the highly descriptive name 'Wrapper' in 
PEP 343.

And explaining the operation of specific contexts is generally nice too.

Stealing Greg's example:

   decimal.Context supports the context management protocol, and 
introduces a new decimal arithmetic context for the duration of the 
with statement.

And the synchronisation example:

   threading.Lock supports the context management protocol, and 
acquires the lock for the duration of the with statement.

And the generic closing example:

   closing supports the context management protocol, and closes the 
supplied resource at the end of the with statement.

And the HTML tag examples:

   The HTML tag objects support the context management protocol, and 
emit opening and closing tags before and after execution of the body 
of the with statement.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From p.f.moore at gmail.com  Wed Jul  6 15:04:32 2005
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 6 Jul 2005 14:04:32 +0100
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
In-Reply-To: <20050706052026.aerf6gnbp7k4kooo@login.werra.lunarpages.com>
References: <20050706052026.aerf6gnbp7k4kooo@login.werra.lunarpages.com>
Message-ID: <79990c6b05070606044e6d8b4e@mail.gmail.com>

On 7/6/05, Michael Chermside <mcherm at mcherm.com> wrote:
> Paul Moore writes:
> > I also like the fact that it offers a neat 1-word name for the
> > generator decorator, "@context".
> 
> Well, ok... does anyone *else* agree? I too saw this and thought "neat!
> a simple one-word name!". But then I started worrying that it's not
> defining the *context*, but rather the *context manager*. While
> "context manager" is a term I could easily imagine associating only
> with 'with' statements, "context" is too general a term... even after
> Python supports 'with' statements I will continue to use "context"
> to mean lots of different things (eg: decimal.context).

Actually, you're starting to persuade me... Although I generally
prefer decorator names which are single words. Along with the at-sign,
underscores make the whole thing look a little too "punctuation-heavy"
for me (and don't suggest camel case, please!).

Paul.

From reinhold-birkenfeld-nospam at wolke7.net  Wed Jul  6 15:14:46 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Wed, 06 Jul 2005 15:14:46 +0200
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <79990c6b05070606044e6d8b4e@mail.gmail.com>
References: <20050706052026.aerf6gnbp7k4kooo@login.werra.lunarpages.com>
	<79990c6b05070606044e6d8b4e@mail.gmail.com>
Message-ID: <daglg6$b03$1@sea.gmane.org>

Paul Moore wrote:
> On 7/6/05, Michael Chermside <mcherm at mcherm.com> wrote:
>> Paul Moore writes:
>> > I also like the fact that it offers a neat 1-word name for the
>> > generator decorator, "@context".
>> 
>> Well, ok... does anyone *else* agree? I too saw this and thought "neat!
>> a simple one-word name!". But then I started worrying that it's not
>> defining the *context*, but rather the *context manager*. While
>> "context manager" is a term I could easily imagine associating only
>> with 'with' statements, "context" is too general a term... even after
>> Python supports 'with' statements I will continue to use "context"
>> to mean lots of different things (eg: decimal.context).
> 
> Actually, you're starting to persuade me... Although I generally
> prefer decorator names which are single words. Along with the at-sign,
> underscores make the whole thing look a little too "punctuation-heavy"
> for me (and don't suggest camel case, please!).

Anything against

@contextmanager

in analogy to

@staticmethod

?

Reinhold

-- 
Mail address is perfectly valid!


From gvanrossum at gmail.com  Wed Jul  6 17:13:50 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Wed, 6 Jul 2005 08:13:50 -0700
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <59e9fd3a0507052116307e4d84@mail.gmail.com>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
Message-ID: <ca471dc2050706081361f64dfc@mail.gmail.com>

On 7/5/05, Andrew Durdin <adurdin at gmail.com> wrote:
> I have written a patch that changes the way triple-quoted strings are
> scanned so that leading whitespace is ignored in much the same way
> that pep 257 handles it for docstrings. Largely this was for a
> learning experience in hacking the parser, but it would be very nice
> IMO if something of this sort could be implemented in a future version
> of Python.

I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI.

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

From thomas at thomas-lotze.de  Wed Jul  6 20:07:45 2005
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Wed, 6 Jul 2005 20:07:45 +0200
Subject: [Python-Dev] Chaining try statements: eltry?
Message-ID: <20050706200745.22493ade.thomas@thomas-lotze.de>

Hi,

this is my first message to this list, so let me say hello first.

I want to ask what you think about introducing a keyword 'eltry' which
would be the counterpart of 'elif' for try statements. This had been
suggested before on python-list a couple of years ago by Jonathan
Gardner, but nothing (that I could find) seems to have come of it.


Starting from PEP 341, the try statement might be extended to

try_stmt: 'try' ':' suite
          (
            (except_clause ':' suite)+
            (
              'eltry' ':' suite
              (except_clause ':' suite)+
            )*
            ['else' ':' suite]
            ['finally' ':' suite]
          |
            'finally' ':' suite
          )

where lines 4 through 7 would be an addition to the definition given in
the PEP. Admittedly, this looks somewhat complex, but I don't think it
actually is. (And while an new keyword always means potentially breaking
code, 'eltry' doesn't seem to me a likely identifier chosen by
programmers - YMMV.)


This extension would be useful whenever a suite of statements is to be
terminated as soon as one of them raises an exception, and the
programmer is interested in handling those individually. Without 'eltry'
the choices are:

- Stack conventional try statements, each inside the else clause of
  the one before. This causes deep nesting, and while typical nesting
  depths won't be as great as they might become with stacked if
  statements, it is annoying and ugly IMO.

- Run all statements at once and put all exception handlers outside the
  suite. This yields code that is harder to read than necessary as some
  handlers will be written far from the statement where the exception
  they handle is raised. Moreover, if more than one statement may raise
  a particular exception, some effort is required to find out which one
  did it if there is only one handler for that exception.

- Break up the suite into separate try statements. While this may result
  in well readable code if each handler breaks out of the block 
  containing the whole run of try statements, it requires some mechanism
  (such as a wrapper try statement or a separate function that may quit
  anytime) if exiting the current block is not desired.

- Something else, in which case I'm looking forward to learning
  something new about Python ;o)


An example would be a filter chain:

def use_eltry(data):
    # decode as far as possible
    try:
        data = foo_decode(data)
    except ValueError:
        print "Data seems not to be foo encoded."
    eltry:
        data = bar_decode(data)
    except ValueError:
        print "Foo decoded data seems not to be bar encoded."
    eltry:
        data = baz_decode(data)
    except ValueError:
        print "FooBar decoded data seems not to be baz encoded."

    # whatever data is by now, do something with it
    do_something(data)


def use_stacking(data):
    # decode as far as possible
    try:
        data = foo_decode(data)
    except ValueError:
        print "Data seems not to be foo encoded."
    else:
        try:
            data = bar_decode(data)
        except ValueError:
            print "Foo decoded data seems not to be bar encoded."
        else:
            try:
                data = baz_decode(data)
            except ValueError:
                print "FooBar decoded data seems not to be baz encoded."

    # whatever data is by now, do something with it
    do_something(data)


def use_single_handler(data):
    # decode as far as possible
    try:
        data = foo_decode(data)
        data = bar_decode(data)
        data = baz_decode(data)
    except ValueError:
        print "Data could not be decoded, can't tell you why easily."

    # whatever data is by now, do something with it
    do_something(data)


def use_custom_exception(data):
    # decode as far as possible
    try:
        try:
            data = foo_decode(data)
        except ValueError:
            print "Data seems not to be foo encoded."
            raise

        try:
            data = bar_decode(data)
        except ValueError:
            print "Foo decoded data seems not to be bar encoded."
            raise

        try:
            data = baz_decode(data)
        except ValueError:
            print "FooBar decoded data seems not to be baz encoded."
            raise
    except ValueError:
        pass

    # whatever data is by now, do something with it
    do_something(data)


def use_function(data):
    # decode as far as possible
    def helper():
        try:
            data = foo_decode(data)
        except ValueError:
            print "Data seems not to be foo encoded."
            return

        try:
            data = bar_decode(data)
        except ValueError:
            print "Foo decoded data seems not to be bar encoded."
            return

        try:
            data = baz_decode(data)
        except ValueError:
            print "FooBar decoded data seems not to be baz encoded."
            return

    helper()

    # whatever data is by now, do something with it
    do_something(data)


Does this seem contrived? (Obviously, I don't think so.) It would be
nice to hear your opinions and, if you don't agree with the proposal,
learn what is bad about it.

-- 

Viele Gr??e,
Thomas

From tjreedy at udel.edu  Wed Jul  6 20:23:26 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 6 Jul 2005 14:23:26 -0400
Subject: [Python-Dev] Triple-quoted strings and indentation
References: <59e9fd3a0507052116307e4d84@mail.gmail.com><dafs0o$4fm$1@sea.gmane.org><59e9fd3a0507060236cddc3ba@mail.gmail.com>
	<59e9fd3a05070602451125d803@mail.gmail.com>
Message-ID: <dah7iv$96i$1@sea.gmane.org>


"Andrew Durdin" <adurdin at gmail.com> wrote in message 
news:59e9fd3a05070602451125d803 at mail.gmail.com...
> Here's the draft PEP I wrote up:

I believe there were some current alternatives and concerns already 
expressed that have not been included yet that maybe should be.

Some of your examples look worse than needed by putting the first line 
after the triple quote instead of escaping the first newline like you did 
elsewhere.

Having separate rules for doc strings and other tq strings would be a 
nuisance.

Terry J. Reedy




From gvanrossum at gmail.com  Wed Jul  6 21:02:14 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Wed, 6 Jul 2005 12:02:14 -0700
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <20050706200745.22493ade.thomas@thomas-lotze.de>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
Message-ID: <ca471dc2050706120231ecb092@mail.gmail.com>

On 7/6/05, Thomas Lotze <thomas at thomas-lotze.de> wrote:
> I want to ask what you think about introducing a keyword 'eltry' which
> would be the counterpart of 'elif' for try statements. This had been
> suggested before on python-list a couple of years ago by Jonathan
> Gardner, but nothing (that I could find) seems to have come of it.

I'm -1 on this. The use case doesn't occur often in my experience and
IMO putting each try statement in the else clause of the previous one
is a fine solution.

I also notice that your only example is very repetitive, and would be
better written as a loop, using Python's dynamic nature:

for decoder in foo_decode, bar_decode, foobar_decode:
    try:
        data = decoder(data)
        break
    except ValueError:
        print "data doesn't seem to be %s-encoded" % decoder.__name__

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

From lode_leroy at hotmail.com  Wed Jul  6 09:08:11 2005
From: lode_leroy at hotmail.com (lode leroy)
Date: Wed, 06 Jul 2005 09:08:11 +0200
Subject: [Python-Dev] using pyhon from the MSYS shell
In-Reply-To: <42CAF1AB.7040002@v.loewis.de>
Message-ID: <BAY22-F213122B849D419DEF9CF3DFFD90@phx.gbl>

>From: "Martin v. Löwis" <martin at v.loewis.de>
>I'm personally in favour of supporting "MSYS" as a target system.
>If you want to do it, I'm willing to review patches, but I'm not
>willing to do them myself, as I don't use MSYS.
>
>If you believe that MSYS is a target system in a way similar to
>mingw32, and to cygwin,

actually, MSYS is the package that has the command line tools
(i.e. bash, tar, cp, automake, ...) required to be able to compile
a native windows binary from a source distribution that is depending
on autotools.

>I believe it should get the same treatment
>as mingw32 and cygwin. That means all places that currently deal
>with either of these two systems should also deal with MSYS in
>a similar way. What this means in actual code, I don't know.
>
>OTOH, I already fail to follow you in the very first assumption:
>why is it that you need to change os.sep on MSYS?

"configure" detects what the install-path is (python -c "print os.syspath")
which returns C:\Python. MSYS uses a bash shell which does not
like "\" but needs "/" as os.sep.

Anyways, in the mean time, it's been solved in the m4 files...
Maybe it's better to ask the automake guys to support Python
with MSYS...

>
>Regards,
>Martin



From markrages at gmail.com  Wed Jul  6 18:46:12 2005
From: markrages at gmail.com (Mark Rages)
Date: Wed, 6 Jul 2005 11:46:12 -0500
Subject: [Python-Dev] Expanding max chunk size to 4GB.
Message-ID: <74ee72ca050706094659b13c@mail.gmail.com>

The RIFF chunk size (used by the Python wave library) is 2GB, because
the length is read as a signed 32-bit integer.

The attached patch to chunk.py raises the limit to 4GB by using a
signed integer.

Is this correct?

Is there a more general solution to 32-bit addressing limitation in
wave files?  Multiple chunks?  Set the length field to zero and let
software assume we only have one chunk?

Regards,
Mark Rages
markrages at gmail.com
-- 
You think that it is a secret, but it never has been one.
  - fortune cookie
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: python.patch
Url: http://mail.python.org/pipermail/python-dev/attachments/20050706/f4ff3b68/python.diff

From gvanrossum at gmail.com  Wed Jul  6 21:17:22 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Wed, 6 Jul 2005 12:17:22 -0700
Subject: [Python-Dev] Expanding max chunk size to 4GB.
In-Reply-To: <74ee72ca050706094659b13c@mail.gmail.com>
References: <74ee72ca050706094659b13c@mail.gmail.com>
Message-ID: <ca471dc2050706121732323f3c@mail.gmail.com>

Looks ok to me, but have you tested this with other software that
reads/writes wave files?

You seem to be speculating about the format where you should be
reading the reference documentation for this file format (alas, I
can't help you find it -- you can Google for it as well as I can :).

Also, patches, are best submitted to SourceForge. Read python.org/dev/.

On 7/6/05, Mark Rages <markrages at gmail.com> wrote:
> The RIFF chunk size (used by the Python wave library) is 2GB, because
> the length is read as a signed 32-bit integer.
> 
> The attached patch to chunk.py raises the limit to 4GB by using a
> signed integer.
> 
> Is this correct?
> 
> Is there a more general solution to 32-bit addressing limitation in
> wave files?  Multiple chunks?  Set the length field to zero and let
> software assume we only have one chunk?
> 
> Regards,
> Mark Rages
> markrages at gmail.com
> --
> You think that it is a secret, but it never has been one.
>   - fortune cookie
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/)

From amk at amk.ca  Wed Jul  6 22:00:03 2005
From: amk at amk.ca (A.M. Kuchling)
Date: Wed, 6 Jul 2005 16:00:03 -0400
Subject: [Python-Dev] Request to add developer
Message-ID: <20050706200003.GB8027@rogue.amk.ca>

I wish to request that 'gregorykjohnson' be added to the Python SF
project.  Gregory is the participant I'm mentoring in Google's Summer
of Code program.  His project is enhancing mailbox.py to give it the
ability to modify mailboxes as well as read them; see
http://gkj.freeshell.org/summer_of_code/ for his proposal and code
sketches.

This project seems to belong in nondist/sandbox/ ; I'll impress upon
him that he shouldn't commit any changes to mailbox.py in the
distribution tree until everything is done.

(Trivia: He'll be the fourth 'Greg' or 'Gregory' with Python commit
privs, breaking the tie between Gregs and Andrews; currently there are
three of each.)

--amk

From python at rcn.com  Wed Jul  6 21:53:43 2005
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 6 Jul 2005 15:53:43 -0400
Subject: [Python-Dev] Request to add developer
In-Reply-To: <20050706200003.GB8027@rogue.amk.ca>
Message-ID: <003401c58264$6a562c60$8d3cc797@oemcomputer>

> I wish to request that 'gregorykjohnson' be added to the Python SF
> project.  

I'll enable the permissions tonight.


Raymond

From python at rcn.com  Wed Jul  6 22:06:06 2005
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 6 Jul 2005 16:06:06 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc2050706120231ecb092@mail.gmail.com>
Message-ID: <003601c58266$2526c4e0$8d3cc797@oemcomputer>

[Thomas Lotze]
> > I want to ask what you think about introducing a keyword 'eltry' 
> > which would be the counterpart of 'elif' for try statements. This 
> > had been suggested before on python-list a couple of years ago by 
> > Jonathan Gardner, but nothing (that I could find) seems to have come

> > of it.

[Guido]
> I'm -1 on this. The use case doesn't occur often in my experience and 
> IMO putting each try statement in the else clause of the previous one 
> is a fine solution.
> 
> I also notice that your only example is very repetitive, and would be 
> better written as a loop, using Python's dynamic nature:
> 
> for decoder in foo_decode, bar_decode, foobar_decode:
>     try:
>         data = decoder(data)
>         break
>     except ValueError:
>         print "data doesn't seem to be %s-encoded" % decoder.__name__

FWIW, the looping solution has worked out well in practice.  From
csv.py:

    for thisType in [int, long, float, complex]:
        try:
            thisType(row[col])
            break
        except (ValueError, OverflowError):
            pass


Raymond

From markrages at gmail.com  Wed Jul  6 22:31:00 2005
From: markrages at gmail.com (Mark Rages)
Date: Wed, 6 Jul 2005 15:31:00 -0500
Subject: [Python-Dev] Expanding max chunk size to 4GB.
In-Reply-To: <ca471dc2050706121732323f3c@mail.gmail.com>
References: <74ee72ca050706094659b13c@mail.gmail.com>
	<ca471dc2050706121732323f3c@mail.gmail.com>
Message-ID: <74ee72ca05070613311c90cedc@mail.gmail.com>

On 7/6/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> Looks ok to me, but have you tested this with other software that
> reads/writes wave files?

It appears to work, but I haven't done enough testing to be confident.

> You seem to be speculating about the format where you should be
> reading the reference documentation for this file format (alas, I
> can't help you find it -- you can Google for it as well as I can :).

This site says it's a "long": http://www.borg.com/~jglatt/tech/wave.htm
This site says it's a "ulong": http://www.borg.com/~jglatt/tech/aboutiff.htm

Unsigned makes more sense, considering it's a byte count and would
never be negative.

I've CC'd Erik de Castro Lopo, whose word is more definitive than
random websites.

> Also, patches, are best submitted to SourceForge. Read python.org/dev/.

Oh, sorry, the patch was only to illustrate my idea.  I'll submit a
proper patch to SF once I hear from Erik.

Regards,
Mark
markrages at gmail
-- 
You think that it is a secret, but it never has been one.
  - fortune cookie

From erikd at mega-nerd.com  Wed Jul  6 22:39:51 2005
From: erikd at mega-nerd.com (Erik de Castro Lopo)
Date: Thu, 7 Jul 2005 06:39:51 +1000
Subject: [Python-Dev] Expanding max chunk size to 4GB.
In-Reply-To: <74ee72ca050706094659b13c@mail.gmail.com>
References: <74ee72ca050706094659b13c@mail.gmail.com>
Message-ID: <20050707063951.691b2064.erikd@mega-nerd.com>

Mark Rages wrote:

> The RIFF chunk size (used by the Python wave library) is 2GB, because
> the length is read as a signed 32-bit integer.
> 
> The attached patch to chunk.py raises the limit to 4GB by using a
> signed integer.
> 
> Is this correct?

The original Microsoft specification listed the chunk size fields
as unsigned 32 bit int, so what you are doing is correct.

However, be aware that many programs (particularly on windows) using
their own WAV file parsing code do not handle file bigger than 2Gig.

> Is there a more general solution to 32-bit addressing limitation in
> wave files? 

No.

> Multiple chunks?

No.

Other file formats allow file sizes larger than 4Gig. I would suggest
you have a look at AU and W64.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam at mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Fundamentalist : Someone who is colour blind and yet wants everyone
else to see the world with the same lack of colour.

From erikd at mega-nerd.com  Wed Jul  6 22:41:42 2005
From: erikd at mega-nerd.com (Erik de Castro Lopo)
Date: Thu, 7 Jul 2005 06:41:42 +1000
Subject: [Python-Dev] Expanding max chunk size to 4GB.
In-Reply-To: <ca471dc2050706121732323f3c@mail.gmail.com>
References: <74ee72ca050706094659b13c@mail.gmail.com>
	<ca471dc2050706121732323f3c@mail.gmail.com>
Message-ID: <20050707064142.27e718d0.erikd@mega-nerd.com>

Guido van Rossum wrote:

> Looks ok to me, but have you tested this with other software that
> reads/writes wave files?

Have a look at the sndfile-info program that is distributed as
part of libnsdifle. If there is anything wrong with the file
you have generated, the output of that program will make it pretty
obvious.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam at mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Neither noise nor information is predictable."
  -- Ray Kurzweil

From erikd at mega-nerd.com  Wed Jul  6 22:44:32 2005
From: erikd at mega-nerd.com (Erik de Castro Lopo)
Date: Thu, 7 Jul 2005 06:44:32 +1000
Subject: [Python-Dev] Expanding max chunk size to 4GB.
In-Reply-To: <74ee72ca05070613311c90cedc@mail.gmail.com>
References: <74ee72ca050706094659b13c@mail.gmail.com>
	<ca471dc2050706121732323f3c@mail.gmail.com>
	<74ee72ca05070613311c90cedc@mail.gmail.com>
Message-ID: <20050707064432.26a58a37.erikd@mega-nerd.com>

Mark Rages wrote:

> This site says it's a "long": http://www.borg.com/~jglatt/tech/wave.htm
> This site says it's a "ulong": http://www.borg.com/~jglatt/tech/aboutiff.htm

Wonderful isn't it :-).

> Unsigned makes more sense, considering it's a byte count and would
> never be negative.
> 
> I've CC'd Erik de Castro Lopo, whose word is more definitive than
> random websites.

libsndfile treats the chunk lengths as unsigned int.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam at mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"It's far too easy to make fun of Microsoft products, but it takes a
real man to make them work, and a god to make them do anything useful"
  -- Anonymous

From tdelaney at avaya.com  Thu Jul  7 01:32:05 2005
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Thu, 7 Jul 2005 09:32:05 +1000
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
Message-ID: <2773CAC687FD5F4689F526998C7E4E5F05CB3B@au3010avexu1.global.avaya.com>

Well, I'm convinced. My votes go to "context management protocol" and
@contextmanager. Simple, descriptive and specific in meaning yet wide
enough to cover pretty much all the cases we care about.

I think we should state in the docs that the most common usage is to set
up a specific context and restore the context to what it was before the
with statement at the end of the with statement. Any other use should
contain dire warnings ;) This works for the HTML tags - the original
context is being outside the <html> tag - and the additional explanation
is sufficient warning IMO.

Tim Delaney

From python at rcn.com  Thu Jul  7 01:47:00 2005
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 6 Jul 2005 19:47:00 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
In-Reply-To: <42CBBC92.4040804@gmail.com>
Message-ID: <000001c58285$013a8200$2601a044@oemcomputer>

[Nick Coghlan]
> OK, here's some draft documentation using Phillip's context
> terminology. I think it works very well.
> 
> """
> With Statements and Context Management
> 
> A frequent need in programming is to ensure a particular action is
> taken after a specific section of code has been executed (such as
> closing a file or releasing a lock). The tool to achieve this in
> Python is to use the 'with' statement along with the appropriate
> context manager.

"the tool"  -->  "a tool"

The other tool is, of course, try/finally.

What is offered by "with" and context manager objects is the
encapulsation specific try/finally blocks.  This enables repeated,
common code to be factored-out.

There only new magic here is factoring.  Context management has always
been possible.



>      __enter__(self):
>      __exit__(self, exc_type, exc_value, exc_traceback):

These names should be changed to __beginwith__ and __endwith__.  The
current names are too vague, not obviously paired with each other, not
obviously tied to the with-statement, and provide no hint about what
calls them.  Remember, the methods will appear among a slew of other
methods that have nothing to do with with-statements.  There will be no
surrounding contextual clue as to what these methods are for.



Raymond

From tdelaney at avaya.com  Thu Jul  7 01:54:28 2005
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Thu, 7 Jul 2005 09:54:28 +1000
Subject: [Python-Dev] 'With' context documentation draft (was
	Re:Terminology for PEP 343
Message-ID: <2773CAC687FD5F4689F526998C7E4E5F05CB40@au3010avexu1.global.avaya.com>

Raymond Hettinger wrote:

> These names should be changed to __beginwith__ and __endwith__.  The

Alternatively:

__begincontext__ / __endcontext__
__enterwith__ / __exitwith__
__entercontext__ / __exitcontext__
__begin_with__ / __end_with__
__begin_context__ / __end_context__
__enter_with__ / __exit_with__
__enter_context__ / __exit_context__

:)

Tim Delaney

From fdrake at acm.org  Thu Jul  7 02:10:10 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 6 Jul 2005 20:10:10 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
In-Reply-To: <000001c58285$013a8200$2601a044@oemcomputer>
References: <000001c58285$013a8200$2601a044@oemcomputer>
Message-ID: <200507062010.11135.fdrake@acm.org>

On Wednesday 06 July 2005 19:47, Raymond Hettinger wrote:
 > These names should be changed to __beginwith__ and __endwith__.  The
 > current names are too vague, not obviously paired with each other, not
 > obviously tied to the with-statement, and provide no hint about what
 > calls them.  Remember, the methods will appear among a slew of other
 > methods that have nothing to do with with-statements.  There will be no
 > surrounding contextual clue as to what these methods are for.

I don't really like this; what's to say there won't be some other client of 
the context protocol?  Should __iter__ have been __iterfor__?  (I don't think 
so.)

If we're worried about name clashes (and in __*__ space, no less!), then 
perhaps it makes sense to do something like __context__ (similar to 
__iter__), and use the __enter__ and __exit__ on the result of that method.

I'm not convinced there's a need to worry about clashes in the __*__ 
namespace, but I can see how it might be nice to provide an __context__ 
method similar to __iter__.  But I don't find it compelling, so... let's have 
__enter__ and __exit__, and be done.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From nidoizo at yahoo.com  Thu Jul  7 03:17:11 2005
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Wed, 06 Jul 2005 21:17:11 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <200507062010.11135.fdrake@acm.org>
References: <000001c58285$013a8200$2601a044@oemcomputer>
	<200507062010.11135.fdrake@acm.org>
Message-ID: <dahvkq$7ua$1@sea.gmane.org>

Fred L. Drake, Jr. wrote:
> On Wednesday 06 July 2005 19:47, Raymond Hettinger wrote:
>  > These names should be changed to __beginwith__ and __endwith__.  The
>  > current names are too vague, not obviously paired with each other, not
>  > obviously tied to the with-statement, and provide no hint about what
>  > calls them.  Remember, the methods will appear among a slew of other
>  > methods that have nothing to do with with-statements.  There will be no
>  > surrounding contextual clue as to what these methods are for.
> 
> I don't really like this; what's to say there won't be some other client of 
> the context protocol?  Should __iter__ have been __iterfor__?  (I don't think 
> so.)

Then what about __begincontext__ and __endcontext__?  Raymond's points 
about __enter__ and __exit__ are still good.

Regards,
Nicolas


From barry at python.org  Thu Jul  7 03:34:51 2005
From: barry at python.org (Barry Warsaw)
Date: Wed, 06 Jul 2005 21:34:51 -0400
Subject: [Python-Dev] 'With' context documentation draft (was
	Re:	Terminology for PEP 343
In-Reply-To: <000001c58285$013a8200$2601a044@oemcomputer>
References: <000001c58285$013a8200$2601a044@oemcomputer>
Message-ID: <1120700091.23658.5.camel@geddy.wooz.org>

+1 on @contextmanager

On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote:

> >      __enter__(self):
> >      __exit__(self, exc_type, exc_value, exc_traceback):
> 
> These names should be changed to __beginwith__ and __endwith__.  

-0.  My fingers are too hardwired to writing "endswith", as in the
string method of similar name.  ;)

Slightly silly alternative: __within__ and __without__

Otherwise, +0 on __enter__ and __exit__.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050706/ef6636e1/attachment.pgp

From dave at boost-consulting.com  Thu Jul  7 04:22:45 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 06 Jul 2005 22:22:45 -0400
Subject: [Python-Dev] GCC version compatibility
Message-ID: <u8y0jz762.fsf@boost-consulting.com>


Recently people testing Boost.Python with GCC on Linux have reported
that the extensions being tested have to be compiled with exactly the
same version of GCC as the Python they're being loaded into, or they
get mysterious crashes.

That doesn't correspond to my past experience; it has always been true
that, as long as the compiler used to build Python and the one used to
build the extension have compatible 'C' ABIs, we've been okay.  Yes,
if you were going to pass types like FILE* across the Python/C API,
then you additionally need to be sure that the two compilers are using
the same 'C' library.  That said, none of the Boost.Python tests do
that.

I'm wondering if there has been a well-known recent change either in Python
or GCC that would account for these new reports.  Any relevant
information would be appreciated.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


From thomas at thomas-lotze.de  Thu Jul  7 10:38:33 2005
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Thu, 7 Jul 2005 10:38:33 +0200
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc2050706120231ecb092@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
Message-ID: <20050707103833.327547ed.thomas@thomas-lotze.de>

Guido van Rossum <gvanrossum at gmail.com> wrote:

> I also notice that your only example is very repetitive, and would be
> better written as a loop, using Python's dynamic nature:

Sure, that's true for the example given. Getting other stuff into a form
which allows for looping may require additional code.

But then, the example was intended to illustrate, not persuade. It's
fine with me if you're determined that eltry is a bad (or at least not
good enough) idea. I do wish for it occasionally, but that's true for a
number of things.

Thinking about it some more, I find that a symmetry between statements
which have an 'else' part would be appealing from an aesthetic point of
view, which includes introduction of 'elfor' and 'elwhile' - or allowing
for syntax like 'else if ...:' and 'else try:'. (It seems some people
favour that anyway. OTOH, I undestand that introducing two-token
constructs doesn't necessarily simplify parsing.) But I haven't
encountered any use cases for that, so it's probably just idle musing.

-- 

Viele Gr??e,
Thomas

From ncoghlan at iinet.net.au  Thu Jul  7 11:44:14 2005
From: ncoghlan at iinet.net.au (Nick Coghlan)
Date: Thu, 07 Jul 2005 19:44:14 +1000
Subject: [Python-Dev] PEP 343 documentation on Sourceforge Patch tracker
Message-ID: <42CCF96E.8000902@iinet.net.au>

I've put the draft documentation on the SF tracker, as Patch ID 
#1234057 [1].

The version posted there has a few changes from the last draft I 
mailed to the list, including:

- mention try/finally, then describe with statements as a way to 
eliminate the associated boilerplate
- clean up some terminology issues in the opening section that were 
holdovers from the 'suite management' version
- switch to contextmanager as the decorator name
- a couple of name changes in the contextmanager sample code
- a few minor editiorial fixes

It still needs addition of latex formatting codes.

I also kept the enter/exit terminology, since that is the only one 
Guido has given blessing to (by approving PEP 343 using those method 
names)

Cheers,
Nick.

[1] http://www.python.org/sf/1234057

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From theller at python.net  Thu Jul  7 11:54:55 2005
From: theller at python.net (Thomas Heller)
Date: Thu, 07 Jul 2005 11:54:55 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
References: <d9mmd6$gjf$1@sea.gmane.org>
	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
	<ca471dc2050703112845321ad3@mail.gmail.com>
	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<50862ebd05070604117e9c5fb4@mail.gmail.com>
Message-ID: <y88j3pqo.fsf@python.net>

Neil Hodgson <nyamatongwe at gmail.com> writes:

> Guido van Rossum:
>
>> Ah, sigh. I didn't know that os.listdir() behaves differently when the
>> argument is Unicode. Does os.listdir(".") really behave differently
>> than os.listdir(u".")? 
>
>    Yes:
>>>> os.listdir(".")
> ['abc', '????????????']
>>>> os.listdir(u".")
> [u'abc', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435']
>
>> Bah! I don't think that's a very good design
>> (although I see where it comes from). 
>
>    Partly my fault. At the time I was more concerned with making
> functionality possible rather than convenient.
>
>> Promoting only those entries
>> that need it seems the right solution -- user code that can't deal
>> with the Unicode entries shouldn't be used around directories
>> containing unicode -- if it needs to work around unicode it should be
>> fixed to support that!

I'm sorry but that's not my opinion.

Code that can't deal with unicode entries is broken, imo.  The
programmer does not know where the user runs this code at what he throws
at it.  I think that this will hide bugs.

When I installed the first game written in Python with pygame on my
daughter's PC it didn't run, simply because there was a font listed in
the registry which contained umlauts somewhere.

OTOH, I once had a bug report from a py2exe user who complained that the
program didn't start when installed in a path with japanese characters
on it.  I tried this out, the bug existed (and still exists), but I was
astonished how many programs behaved the same: On a PC with english
language settings, you cannot start WinZip or Acrobat Reader (to give
just some examples) on a .zip or .pdf file contained in such a
directory.

>    OK, I'll work on a patch for that but I'd like to see the opinions
> of the usual unicode guys as this will produce more opportunities for
> UnicodeDecodeError. The modification will probably work in the
> opposite way, asking for all the names in unicode and then attempting
> to convert to the default code page with failures retaining the
> unicode name.

Thomas


From fpillet at gmail.com  Thu Jul  7 14:17:13 2005
From: fpillet at gmail.com (Florent Pillet)
Date: Thu, 7 Jul 2005 14:17:13 +0200
Subject: [Python-Dev] C bindings calling tmpfile() blocks interrupt signal
Message-ID: <d143d3ff0507070517154ec286@mail.gmail.com>

I discovered an issue on Mac OS X that seems to relate to signal
handling. I have a C binding in which I call the standard tmpfile()
function. After calling it, I can't break Python anymore with CTRL-C.

Investigating the Darwin source code for tmpfile() (and FreeBSD, they
are the same) , I found that the function is mucking with the signals:

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/tmpfile.c?rev=1.9&content-type=text/x-cvsweb-markup

Is this considered a Python issue, or an OS issue? I ran a simple test
against the interrupt signal, which didn't show any wrong behavior:

static void intcatcher(int sig) {
    printf("Interrupt catched\n");
    exit(1);
}
int main(int argc, char **argv) {
    signal(SIGINT, intcatcher);
    printf("Press CTRL-C to interrupt...\n");
    tmpfile();
    while (1)
        ;
    return 0;
}

But with my threaded Python code, SIGINT doesn't work anymore after my
binding has called tmpfile().

Florent

-- 
Florent Pillet                  http://www.florentpillet.com
Freelance software developer/consultant - Palm OS & Mac OS X
ICQ: 117292463                Skype: callto://florent.pillet

From mwh at python.net  Thu Jul  7 14:28:00 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 07 Jul 2005 13:28:00 +0100
Subject: [Python-Dev] 'With' context documentation draft (was
	Re:	Terminology for PEP 343
In-Reply-To: <1120700091.23658.5.camel@geddy.wooz.org> (Barry Warsaw's
	message of "Wed, 06 Jul 2005 21:34:51 -0400")
References: <000001c58285$013a8200$2601a044@oemcomputer>
	<1120700091.23658.5.camel@geddy.wooz.org>
Message-ID: <2mpstuvm0f.fsf@starship.python.net>

Barry Warsaw <barry at python.org> writes:

> +1 on @contextmanager
>
> On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote:
>
>> >      __enter__(self):
>> >      __exit__(self, exc_type, exc_value, exc_traceback):
>> 
>> These names should be changed to __beginwith__ and __endwith__.  

-1.

> -0.  My fingers are too hardwired to writing "endswith", as in the
> string method of similar name.  ;)
>
> Slightly silly alternative: __within__ and __without__

Meh.

> Otherwise, +0 on __enter__ and __exit__.

+1 from me.

Cheers,
mwh

-- 
58. Fools ignore complexity. Pragmatists suffer it. Some can avoid
    it. Geniuses remove it.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

From mwh at python.net  Thu Jul  7 14:58:23 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 07 Jul 2005 13:58:23 +0100
Subject: [Python-Dev] C bindings calling tmpfile() blocks interrupt
 signal
In-Reply-To: <d143d3ff0507070517154ec286@mail.gmail.com> (Florent Pillet's
	message of "Thu, 7 Jul 2005 14:17:13 +0200")
References: <d143d3ff0507070517154ec286@mail.gmail.com>
Message-ID: <2mhdf6vkls.fsf@starship.python.net>

Florent Pillet <fpillet at gmail.com> writes:

> I discovered an issue on Mac OS X that seems to relate to signal
> handling. I have a C binding in which I call the standard tmpfile()
> function. After calling it, I can't break Python anymore with CTRL-C.

> Investigating the Darwin source code for tmpfile() (and FreeBSD, they
> are the same) , I found that the function is mucking with the signals:
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/tmpfile.c?rev=1.9&content-type=text/x-cvsweb-markup
>
> Is this considered a Python issue, or an OS issue? 

Um, I don't know.  That function certainly looks like it's trying to
pt the signal mask back.

> I ran a simple test against the interrupt signal, which didn't show
> any wrong behavior:
>
> static void intcatcher(int sig) {
>     printf("Interrupt catched\n");
>     exit(1);
> }
> int main(int argc, char **argv) {
>     signal(SIGINT, intcatcher);
>     printf("Press CTRL-C to interrupt...\n");
>     tmpfile();
>     while (1)
>         ;
>     return 0;
> }
>
> But with my threaded Python code, SIGINT doesn't work anymore after my
> binding has called tmpfile().

Oh, threads.

Which version of Python are you using?

Cheers,
mwh

-- 
  > So what does "abc" / "ab" equal?
  cheese
         -- Steve Holden defends obscure semantics on comp.lang.python

From dave at boost-consulting.com  Thu Jul  7 15:16:16 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 09:16:16 -0400
Subject: [Python-Dev] Linux Python linking with G++?
Message-ID: <u64vmycwv.fsf@boost-consulting.com>

An embedded message was scrubbed...
From: unknown sender
Subject: Topics
Date: no date
Size: 183
Url: http://mail.python.org/pipermail/python-dev/attachments/20050707/af1aa42a/attachment.eml
-------------- next part --------------
An embedded message was scrubbed...
From: Douglas Gregor <doug.gregor at gmail.com>
Subject: Re: Regressions in your Boost libraries as of 2005-07-06
Date: Wed, 6 Jul 2005 21:28:18 -0500
Size: 1603
Url: http://mail.python.org/pipermail/python-dev/attachments/20050707/af1aa42a/attachment-0001.eml
-------------- next part --------------
An embedded message was scrubbed...
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
Subject: Re: Regressions in your Boost libraries as of 2005-07-06
Date: Wed, 6 Jul 2005 19:04:11 -0700 (PDT)
Size: 2082
Url: http://mail.python.org/pipermail/python-dev/attachments/20050707/af1aa42a/attachment-0002.eml

From sjoerd at acm.org  Thu Jul  7 15:38:26 2005
From: sjoerd at acm.org (Sjoerd Mullender)
Date: Thu, 07 Jul 2005 15:38:26 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <u64vmycwv.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>
Message-ID: <42CD3052.6000704@acm.org>

David Abrahams wrote:
> Apparently Python on some linux distros is being linked by g++ rather
> than gcc, resulting in the C++ runtime library being linked into
> Python; this has bad consequences for compatibility between C++
> extension modules and Pythons that have been built with different
> versions of GCC.  Is this behavior intentional?

Configure with --without-cxx to not use g++.  Since there is an option
in configure, I assume it is intentional.

-- 
Sjoerd Mullender

From gvanrossum at gmail.com  Thu Jul  7 15:39:30 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Thu, 7 Jul 2005 06:39:30 -0700
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <20050707103833.327547ed.thomas@thomas-lotze.de>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
Message-ID: <ca471dc2050707063938b19fb2@mail.gmail.com>

On 7/7/05, Thomas Lotze <thomas at thomas-lotze.de> wrote:
> Sure, that's true for the example given. Getting other stuff into a form
> which allows for looping may require additional code.

Well, hypothetical illustrations don't carry much value when arguing
for something as substantial as new syntax requiring a new keyword.
You have to present an actual use case with an indication (even if
only anecdotal) of how common the use case is, and an explanation why
the existing ways of handling that use case are inadequate.

Your illustration doesn't count as a use case because it is easily
handled already.

> Thinking about it some more, I find that a symmetry between statements
> which have an 'else' part would be appealing from an aesthetic point of
> view, which includes introduction of 'elfor' and 'elwhile' - or allowing
> for syntax like 'else if ...:' and 'else try:'. (It seems some people
> favour that anyway. OTOH, I undestand that introducing two-token
> constructs doesn't necessarily simplify parsing.) But I haven't
> encountered any use cases for that, so it's probably just idle musing.

The parsing would be easy enough (and in fact I sometimes think it was
a mistake to introduce elif just to save typing "else if".

The problem with the elwhile/elfor/eltry idea (apart from the
explosion of new keywords) is that you're just as likely to need e.g.
a "try" in the else clause of a while-loop as another while, so you'd
end up having all combinations in the syntax. Since, as you say, the
use cases are rare, the syntactic complexity isn't worth it.

I even wonder if else-clauses on for/while were a good idea. (The one
on try is definitely a good idea since the use case is quite frequent
and only clumsily handled otherwise; the use cases for else on
for/while are less convincing IMO.)

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

From tzot at mediconsa.com  Thu Jul  7 16:16:27 2005
From: tzot at mediconsa.com (Christos Georgiou)
Date: Thu, 7 Jul 2005 17:16:27 +0300
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API
	forsets.Set and build-in set)
References: <000a01c57dba$520e8700$1330cb97@oemcomputer><200506301743.32417.fdrake@acm.org>
	<1f7befae05063015207acb85dc@mail.gmail.com>
Message-ID: <dajdfp$rgl$1@sea.gmane.org>


"Tim Peters" <tim.peters at gmail.com> wrote in message 
news:1f7befae05063015207acb85dc at mail.gmail.com...

> Or my personal favorite,
>
>    while mylist:
>        del mylist[::2]
>
> Then the original index positions with the most consecutive trailing 1
> bits survive the longest, which is important to avoid ZODB cache bugs
> <wink>.

This is a joke, hopefully, and in that case, I fell for it.  If not, please 
provide a url with related discussion (for educational purposes :) 



From dave at boost-consulting.com  Thu Jul  7 16:28:15 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 10:28:15 -0400
Subject: [Python-Dev] Linux Python linking with G++?
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
Message-ID: <uy88ivgg0.fsf@boost-consulting.com>

Sjoerd Mullender <sjoerd at acm.org> writes:

> David Abrahams wrote:
>> Apparently Python on some linux distros is being linked by g++ rather
>> than gcc, resulting in the C++ runtime library being linked into
>> Python; this has bad consequences for compatibility between C++
>> extension modules and Pythons that have been built with different
>> versions of GCC.  Is this behavior intentional?
>
> Configure with --without-cxx to not use g++.  Since there is an option
> in configure, I assume it is intentional.

O-kay... any idea what the rationale for this decision might be?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


From tim.peters at gmail.com  Thu Jul  7 16:31:43 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 7 Jul 2005 10:31:43 -0400
Subject: [Python-Dev] List copy and clear (was Re: Inconsistent API
	forsets.Set and build-in set)
In-Reply-To: <dajdfp$rgl$1@sea.gmane.org>
References: <000a01c57dba$520e8700$1330cb97@oemcomputer>
	<200506301743.32417.fdrake@acm.org>
	<1f7befae05063015207acb85dc@mail.gmail.com>
	<dajdfp$rgl$1@sea.gmane.org>
Message-ID: <1f7befae05070707313d5d8eaf@mail.gmail.com>

[Tim Peters]
>> Or my personal favorite,
>>
>>    while mylist:
>>        del mylist[::2]
>>
>> Then the original index positions with the most consecutive trailing 1
>> bits survive the longest, which is important to avoid ZODB cache bugs
>> <wink>.

[Christos Georgiou]
> This is a joke, hopefully, and in that case, I fell for it.  If not, please
> provide a url with related discussion (for educational purposes :)

Fell for what?  It's certainly true that the code snippet allows the
original index positions with the most consecutive trailing 1 bits to
survive the longest (on the first iteration, all even index positions
(no trailing 1 bits) are deleted, and you don't really need a URL to
figure out what happens on the i'th iteration).  The idea that this is
helpful in avoiding anything's "cache bugs" is purely <wink>-worthy,
though.

From skip at pobox.com  Thu Jul  7 16:43:56 2005
From: skip at pobox.com (Skip Montanaro)
Date: Thu, 7 Jul 2005 09:43:56 -0500
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <uy88ivgg0.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
Message-ID: <17101.16300.736797.378762@montanaro.dyndns.org>


    >> Configure with --without-cxx to not use g++.  Since there is an
    >> option in configure, I assume it is intentional.

    Dave> O-kay... any idea what the rationale for this decision might be?

I believe it's so that people can link in libraries written in C++ and have
them initialized properly.

Skip

From pinard at iro.umontreal.ca  Thu Jul  7 18:34:52 2005
From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard)
Date: Thu, 7 Jul 2005 12:34:52 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc2050707063938b19fb2@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
Message-ID: <20050707163452.GA12703@phenix.progiciels-bpi.ca>

[Guido van Rossum]

> I even wonder if else-clauses on for/while were a good idea.

I surely find them useful, and see them as a Python originality (a
welcome one).

-- 
Fran?ois Pinard   http://pinard.progiciels-bpi.ca

From gvanrossum at gmail.com  Thu Jul  7 19:48:39 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Thu, 7 Jul 2005 10:48:39 -0700
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <20050707163452.GA12703@phenix.progiciels-bpi.ca>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
Message-ID: <ca471dc205070710484a5894c4@mail.gmail.com>

On 7/7/05, Fran?ois Pinard <pinard at iro.umontreal.ca> wrote:
> [Guido van Rossum]
> 
> > I even wonder if else-clauses on for/while were a good idea.
> 
> I surely find them useful, and see them as a Python originality (a
> welcome one).

They are indeed an original invention. (One day I looked at the
similarity between if and while and noticed that there was a use case
for else after while too.)

The question remains whether Python would be easier to learn without
them. And if so, the question would remain whether that's offset by
their utility for experienced developers. All hard to assess
impartially!

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

From gvanrossum at gmail.com  Thu Jul  7 20:00:58 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Thu, 7 Jul 2005 11:00:58 -0700
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
In-Reply-To: <2mpstuvm0f.fsf@starship.python.net>
References: <000001c58285$013a8200$2601a044@oemcomputer>
	<1120700091.23658.5.camel@geddy.wooz.org>
	<2mpstuvm0f.fsf@starship.python.net>
Message-ID: <ca471dc205070711001297f0bf@mail.gmail.com>

> > +1 on @contextmanager

+1.

[__enter__, __exit__]
> >> These names should be changed to __beginwith__ and __endwith__.

-1.  The PEP has had an extensive review period and several
alternatives were discussed and rejected. These names are clear, they
*do* match, and as Fred says the __*__ namespace has lots of room.

Also, the PEP was accepted with these names. Now, if it was accepted
with a major flaw or some semantics left unspecified, I'd be happy to
discuss repairs; but there's nothing broken about this part of the
PEP, so I say enough is enough (and none of the proposals sound good
to me anyway so I'd be -1 even if the PEP was still under discussion).

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

From pje at telecommunity.com  Thu Jul  7 20:19:28 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 07 Jul 2005 14:19:28 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42CBBC92.4040804@gmail.com>
References: <42C91A07.9030402@gmail.com>
	<000701c57e8f$86c35ae0$aa36c797@oemcomputer>
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>
	<42C91A07.9030402@gmail.com>
Message-ID: <5.1.1.6.0.20050707141420.02674e58@mail.telecommunity.com>

At 09:12 PM 7/6/2005 +1000, Nick Coghlan wrote:
>Another example is the use of contexts to handle insertion of the
>appropriate tags when generating HTML:
>
>     with html:
>        with body:
>           with h1:
>              print "Some heading"
>           with p:
>              print "This is paragraph 1"
>           with p:
>              print "This is paragraph 2"
>           with h2:
>              print "Another heading"

I suggest changing this to something like this:

     class tag(object):
         def __init__(self,name):
             self.name = name
         def __enter__(self):
             print "<%s>" % name
         def __exit__(self):
             print "</%s>" % name

     with tag('html'):
         # ... etc.

So that it's obvious where the implementation is coming from.  Otherwise, 
it looks altogether too magical.

Also, the posted draft doesn't explain what happens to the __enter__ return 
value, either in a literal sense or in the sense of where it fits in the 
overall concept of context management.


From jcarlson at uci.edu  Thu Jul  7 20:35:01 2005
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu, 07 Jul 2005 11:35:01 -0700
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc205070710484a5894c4@mail.gmail.com>
References: <20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
Message-ID: <20050707111529.7118.JCARLSON@uci.edu>


Guido van Rossum <gvanrossum at gmail.com> wrote:
> 
> On 7/7/05, Fran?ois Pinard <pinard at iro.umontreal.ca> wrote:
> > [Guido van Rossum]
> > 
> > > I even wonder if else-clauses on for/while were a good idea.
> > 
> > I surely find them useful, and see them as a Python originality (a
> > welcome one).
> 
> They are indeed an original invention. (One day I looked at the
> similarity between if and while and noticed that there was a use case
> for else after while too.)
> 
> The question remains whether Python would be easier to learn without
> them. And if so, the question would remain whether that's offset by
> their utility for experienced developers. All hard to assess
> impartially!

(data point)

I had gotten along for 5 years without knowing/remembering there existed
an else clause in for and while loops until the beginnings of the
thunk/block/with discussion in February or March.  Commercial work puts
me at around 30k lines of Python in the last year.  In the last 3-4
months, I've used the else clause on for and while around 5 times.

In looking at the tutorial, I notice that else clauses on loops is
discussed a few sections after discussion on the loops themselves.  This
seems like a reasonable location to me, though to be sure, we should
find some people, get them to learn Python through the tutorial, then
ask them what they thought of the tutorial on else clauses in for and
while loops, and whether or not they confused them.

 - Josiah


From tim.peters at gmail.com  Thu Jul  7 20:48:53 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 7 Jul 2005 14:48:53 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc205070710484a5894c4@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
Message-ID: <1f7befae05070711484f214a4@mail.gmail.com>

[Guido, on {for,while}/else]
...
> The question remains whether Python would be easier to learn without
> them. And if so, the question would remain whether that's offset by
> their utility for experienced developers. All hard to assess
> impartially!

That's what I'm here for.  I like loop "else" clauses, but have to
admit that (a) I rarely use them; (b) most of the time I use them, my
control flow is on the way to becoming so convoluted that I'm going to
rewrite the whole function soon anyway; and, (c) I've often misread
code that uses them, mentally attaching the "else" to a nearby "if"
instead.

I also suspect that if they weren't in the language already, a PEP to
introduce them would fail, because

    still_looking = True
    some loop:
        if found it:
            still_looking = False
            break
    if still_looking:
        # what would have been in the "else" clause

is clear and easy to write without it.

From gvanrossum at gmail.com  Thu Jul  7 20:54:49 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Thu, 7 Jul 2005 11:54:49 -0700
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <1f7befae05070711484f214a4@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<1f7befae05070711484f214a4@mail.gmail.com>
Message-ID: <ca471dc20507071154449e8dcd@mail.gmail.com>

> [Guido, on {for,while}/else]
> ...
> > The question remains whether Python would be easier to learn without
> > them. And if so, the question would remain whether that's offset by
> > their utility for experienced developers. All hard to assess
> > impartially!

[Tim saves the day]
> That's what I'm here for.  I like loop "else" clauses, but have to
> admit that (a) I rarely use them; (b) most of the time I use them, my
> control flow is on the way to becoming so convoluted that I'm going to
> rewrite the whole function soon anyway; and, (c) I've often misread
> code that uses them, mentally attaching the "else" to a nearby "if"
> instead.
> 
> I also suspect that if they weren't in the language already, a PEP to
> introduce them would fail, because
> 
>     still_looking = True
>     some loop:
>         if found it:
>             still_looking = False
>             break
>     if still_looking:
>         # what would have been in the "else" clause
> 
> is clear and easy to write without it.

OTOH I don't particularly like code that requires flag variables; they
often make me squirm because the same condition (flag) is tested
multiple times where it could be tested just once if more
sophisticated flow control (e.g. an else clause :) was available.

How would a PEP to *remove* this feature fare today?

Unhelpfully,

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

From dave at boost-consulting.com  Thu Jul  7 20:57:55 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 14:57:55 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<1f7befae05070711484f214a4@mail.gmail.com>
Message-ID: <u7jg2tpe4.fsf@boost-consulting.com>

Tim Peters <tim.peters at gmail.com> writes:

> I also suspect that if they weren't in the language already, a PEP to
> introduce them would fail, because
>
>     still_looking = True
>     some loop:
>         if found it:
>             still_looking = False
>             break
>     if still_looking:
>         # what would have been in the "else" clause
>
> is clear and easy to write without it.

Oh, that's wierd.  I didn't know there were "else" clauses for loops,
but I would've expected the other semantics.  That is, either the loop
terminates normally, "else:" whatever.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


From dave at boost-consulting.com  Thu Jul  7 20:54:40 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 14:54:40 -0400
Subject: [Python-Dev] Linux Python linking with G++?
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
Message-ID: <ud5putpjj.fsf@boost-consulting.com>

Skip Montanaro <skip at pobox.com> writes:

>     >> Configure with --without-cxx to not use g++.  Since there is an
>     >> option in configure, I assume it is intentional.
>
>     Dave> O-kay... any idea what the rationale for this decision might be?
>
> I believe it's so that people can link in libraries written in C++ and have
> them initialized properly.

Can you give specifics?  What do you mean by "link in?"  Do you mean
"statically link into the Python interpreter," or something else?

Boost.Python is a library written in C++ and I've never had trouble
using it with a Python executable... until I ran into a Python that was
linked with libstdc++!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


From pje at telecommunity.com  Thu Jul  7 21:03:35 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 07 Jul 2005 15:03:35 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <1f7befae05070711484f214a4@mail.gmail.com>
References: <ca471dc205070710484a5894c4@mail.gmail.com>
	<20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
Message-ID: <5.1.1.6.0.20050707145039.0267e0c0@mail.telecommunity.com>

At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
>[Guido, on {for,while}/else]
>...
> > The question remains whether Python would be easier to learn without
> > them. And if so, the question would remain whether that's offset by
> > their utility for experienced developers. All hard to assess
> > impartially!
>
>That's what I'm here for.  I like loop "else" clauses, but have to
>admit that (a) I rarely use them; (b) most of the time I use them, my
>control flow is on the way to becoming so convoluted that I'm going to
>rewrite the whole function soon anyway;

Interesting; I usually intentionally write "else" clauses intending to 
*clarify* the code.  That is, I often use it in cases where it's not 
strictly necessary, e.g.:

    for thing in something:
        if blah:
            return thing
    else:
        return None

Because to me this clarifies that 'return None' is what happens if the loop 
"fails".  Compare to:

    for thing in something:
        if blah:
            return thing
    return None

This looks to me at first glance like code that always returns None after 
looping over 'something'.

Of course, these are trivial examples where reading the whole thing isn't a 
big deal; I'm more likely to use it when the loop or surrounding logic are 
a bit more complex, but I do also use it for fairly simple cases.

The interesting thing is that I think it *clarifies* the intent of the 
code, but I guess maybe that's only true for a small subset of Python 
programmers.

I suppose I wouldn't raise much of a fuss if the feature went away in 3.0, 
but I think I would miss it.


>I also suspect that if they weren't in the language already, a PEP to
>introduce them would fail, because
>
>     still_looking = True
>     some loop:
>         if found it:
>             still_looking = False
>             break
>     if still_looking:
>         # what would have been in the "else" clause
>
>is clear and easy to write without it.

*shudder* Okay, you just convinced me.  "Else" should stay, because the 
above is much less readable and writable!


From aahz at pythoncraft.com  Thu Jul  7 21:07:02 2005
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 7 Jul 2005 12:07:02 -0700
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc20507071154449e8dcd@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<1f7befae05070711484f214a4@mail.gmail.com>
	<ca471dc20507071154449e8dcd@mail.gmail.com>
Message-ID: <20050707190702.GA10337@panix.com>

On Thu, Jul 07, 2005, Guido van Rossum wrote:
>
> OTOH I don't particularly like code that requires flag variables; they
> often make me squirm because the same condition (flag) is tested
> multiple times where it could be tested just once if more
> sophisticated flow control (e.g. an else clause :) was available.

That's what I use try/except for.  ;-)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From pinard at iro.umontreal.ca  Thu Jul  7 21:16:34 2005
From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard)
Date: Thu, 7 Jul 2005 15:16:34 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc205070710484a5894c4@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
Message-ID: <20050707191634.GA16539@phenix.progiciels-bpi.ca>

[Guido van Rossum]
> On 7/7/05, Fran?ois Pinard <pinard at iro.umontreal.ca> wrote:
> > [Guido van Rossum]

> > > I even wonder if else-clauses on for/while were a good idea.

> > I surely find them useful, and see them as a Python originality (a
> > welcome one).

> The question remains whether Python would be easier to learn without
> them.

Some of my co-workers, while being very dedicated and efficient to the
production duties, are not especially fond on computer languages, and
have only moderate pleasure learning them.  They are very good people
nevertheless! :-) After PL/I, C, some obscure languages you do not even
know, and now Python, they receive it as just yet another in the series,
and they accept taming themselves, slowly, around Python.  I saw that
the `else:' clause to `for' and `while' has been a surprise to them, and
observe that they usually do not readily recognise cases where it would
be useful.  Yet, others in the gang are more enthusiastic, and they do
not trip at all over various `else:'s.  So, it much depends on the kind
of relation between programmers and languages.

You know, Python would be easier to learn without all `__xyz__' methods,
and without meta-classes :-). [Yet my feeling is that people overdo the
difficulty of meta-classes, which do not deserve the prejudice they
got.]  The learning curve of `else:' is much smoother by comparison.
`else:' _are_ useful in my experience, as I know I used stunts for years
in other languages for achieving about the same effect.  These are for
elementary or basic day-to-day algorithms, and I cannot believe common
problems are so different between a programmer and another.

> All hard to assess impartially!

Granted.  That's why I throw my opinion in this forum.

-- 
Fran?ois Pinard   http://pinard.progiciels-bpi.ca

From tim.peters at gmail.com  Thu Jul  7 21:17:39 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 7 Jul 2005 15:17:39 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc20507071154449e8dcd@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<1f7befae05070711484f214a4@mail.gmail.com>
	<ca471dc20507071154449e8dcd@mail.gmail.com>
Message-ID: <1f7befae0507071217399243b4@mail.gmail.com>

[Guido]
> OTOH I don't particularly like code that requires flag variables;

Me neither; that's indeed why this one isn't a slam dunk.

> they often make me squirm because the same condition (flag) is
> tested multiple times where it could be tested just once if more
> sophisticated flow control (e.g. an else clause :) was available.

What burns me (far) more often in practice is "simulating" a
multi-level `break` or `continue`.  Then multiple flag variables get
introduced, set, and tested multiple times at multiple "logical indent
levels" too.  That can also be viewed as stemming from a lack of more
sophisticated flow control.  One-loop found-it-or-didn't kinds of flag
variables have spatial locality that makes them (IME) quite easy to
live with, in comparison.

> How would a PEP to *remove* this feature fare today?

Easy:  it would be rejected, but with a note that it should be
reconsidered for Python 3000.

> Unhelpfully,

your-opposite-in-oh-so-many-ways<wink>-ly y'rs  - tim

From barry at python.org  Thu Jul  7 21:20:33 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 07 Jul 2005 15:20:33 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc20507071154449e8dcd@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<1f7befae05070711484f214a4@mail.gmail.com>
	<ca471dc20507071154449e8dcd@mail.gmail.com>
Message-ID: <1120764033.10491.26.camel@geddy.wooz.org>

On Thu, 2005-07-07 at 14:54, Guido van Rossum wrote:

> How would a PEP to *remove* this feature fare today?

Not well, I hope, although I suppose everything's up for debate in Py3K.

Yes, they're rarely used and there is an alternative, but I do find them
useful and succinct when they're needed.  Also, I don't think they're
really much of a burden on newbies because mostly, they just don't
encounter them or need to know about them.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050707/373ed5bb/attachment.pgp

From pinard at iro.umontreal.ca  Thu Jul  7 21:40:37 2005
From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard)
Date: Thu, 7 Jul 2005 15:40:37 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <20050707111529.7118.JCARLSON@uci.edu>
References: <20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<20050707111529.7118.JCARLSON@uci.edu>
Message-ID: <20050707194037.GA17982@phenix.progiciels-bpi.ca>

[Josiah Carlson]

> > > [Guido van Rossum]

> > > > I even wonder if else-clauses on for/while were a good idea.

> I had gotten along for 5 years without knowing/remembering there existed
> an else clause [...]

Just throwing a few more cents in.  I have been programming (rather
successfully) for a few dozens of years without such `else:' clauses,
and for example, nearly as long without integrated object orientation.
Such things are not mandatory: we all know how to manage without them.
It is just that, when such features are known and available, they
alleviate programming work, sometimes a bit, sometimes more, depending.

Similarly, for anyone reasonable, there is no real urge nor fundamental
necessity (bugs excepted) going from Python 2.0 to 2.4.  We may
undoubtedly enjoy new features once they happen to be there, but could
well continue to live a successful programming life without them.
`else:' falls in this category.  It is nice and helpful to have, but is
only one of the now numerous features of Python which are not essential.

The fact that we can go without knowing something does not mean that
this something is not welcome.  Some priests do not know sex! :-)

-- 
Fran?ois Pinard   http://pinard.progiciels-bpi.ca

From jhylton at gmail.com  Thu Jul  7 21:42:58 2005
From: jhylton at gmail.com (Jeremy Hylton)
Date: Thu, 7 Jul 2005 15:42:58 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc205070710484a5894c4@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
Message-ID: <e8bf7a530507071242ffe0219@mail.gmail.com>

On 7/7/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> The question remains whether Python would be easier to learn without
> them. And if so, the question would remain whether that's offset by
> their utility for experienced developers. All hard to assess
> impartially!

I think Python would clearly be easier to learn without them-- less
syntax and semantics for loops that are in almost every program.  I
hardly ever use them myself, and I doubt that I'd really miss them. 
(Every time they come up, I need to think carefully about what they
mean.)

As for impartial assessment, how many uses are there in the standard
library?  How many of those uses are clearer than other alternatives? 
Seems like an assessment of those questions is within reach.

Jeremy

PS Every time I switch between Python and C, I get confused about
"elif" and "else if".

From tim.peters at gmail.com  Thu Jul  7 21:58:22 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 7 Jul 2005 15:58:22 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <e8bf7a530507071242ffe0219@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<e8bf7a530507071242ffe0219@mail.gmail.com>
Message-ID: <1f7befae0507071258651bebfd@mail.gmail.com>

[Jeremy Hylton]
> ...
> PS Every time I switch between Python and C, I get confused about
> "elif" and "else if".

Mostly goes to show that you don't use Perl much ;-)  Of course, in C99,

#define elif else if

is part of <stdlib.h>.  Or maybe it isn't, and it just should have
been?  One of those -- or close enough.

From bcannon at gmail.com  Thu Jul  7 22:22:36 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 7 Jul 2005 13:22:36 -0700
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <1f7befae0507071217399243b4@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<1f7befae05070711484f214a4@mail.gmail.com>
	<ca471dc20507071154449e8dcd@mail.gmail.com>
	<1f7befae0507071217399243b4@mail.gmail.com>
Message-ID: <bbaeab10050707132238085d24@mail.gmail.com>

On 7/7/05, Tim Peters <tim.peters at gmail.com> wrote:
> [Guido]
> > OTOH I don't particularly like code that requires flag variables;
> 
> Me neither; that's indeed why this one isn't a slam dunk.
> 
> > they often make me squirm because the same condition (flag) is
> > tested multiple times where it could be tested just once if more
> > sophisticated flow control (e.g. an else clause :) was available.
> 
> What burns me (far) more often in practice is "simulating" a
> multi-level `break` or `continue`.  Then multiple flag variables get
> introduced, set, and tested multiple times at multiple "logical indent
> levels" too.  That can also be viewed as stemming from a lack of more
> sophisticated flow control.  One-loop found-it-or-didn't kinds of flag
> variables have spatial locality that makes them (IME) quite easy to
> live with, in comparison.
> 
> > How would a PEP to *remove* this feature fare today?
> 
> Easy:  it would be rejected, but with a note that it should be
> reconsidered for Python 3000.
> 

Barry also reiterated this idea and I support removing them in Python
3000.  I do use them when I want to know when I break out of a loop
prematurely, but I am definitely not a typical use case for
experienced users since I basically learned how to program in Python
so I didn't have any baggage preventing me from not remembering they
existed.

Simplifying the basic control flow mechanisms is always good.  And as
Aahz pointed out, you can use exceptions to break out of a loop easily
enough and have code for only when you break out with the exception
(maybe we should add a ControlFlowException in Py3000 that all other
control flow exceptions, like StopIteration inherit from?).  In other
words they are not critical and not used frequently from what it
sounds like.  And even in the cases where they are used they can be
reworked to not need them without much hassle.

-Brett

From bcannon at gmail.com  Thu Jul  7 22:30:23 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 7 Jul 2005 13:30:23 -0700
Subject: [Python-Dev] Another SoC student for CVS access
Message-ID: <bbaeab1005070713306f1f34b5@mail.gmail.com>

Floris is working on wrapping Hotshot to replace 'profile' and
replacing pstats so that there will be no more need for 'profile' and
thus take care of the licensing problem.  He also hopes to make pstats
faster to use.  And if we are really lucky, get threading working for
Hotshot.

It would be great to give him CVS access so he can work in nondist. 
His username is sirolf .  He knows he is not to touch anything outside
of his directory in nondist.

-Brett

From jhylton at gmail.com  Thu Jul  7 22:32:13 2005
From: jhylton at gmail.com (Jeremy Hylton)
Date: Thu, 7 Jul 2005 16:32:13 -0400
Subject: [Python-Dev] Another SoC student for CVS access
In-Reply-To: <bbaeab1005070713306f1f34b5@mail.gmail.com>
References: <bbaeab1005070713306f1f34b5@mail.gmail.com>
Message-ID: <e8bf7a53050707133241583242@mail.gmail.com>

On 7/7/05, Brett Cannon <bcannon at gmail.com> wrote:
> Floris is working on wrapping Hotshot to replace 'profile' and
> replacing pstats so that there will be no more need for 'profile' and
> thus take care of the licensing problem.  He also hopes to make pstats
> faster to use.  And if we are really lucky, get threading working for
> Hotshot.

I don't think we actually want to get rid of profile and replace it
with hotshot.  We want to have both tools available.

Jeremy

From skip at pobox.com  Thu Jul  7 22:35:39 2005
From: skip at pobox.com (Skip Montanaro)
Date: Thu, 7 Jul 2005 15:35:39 -0500
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <ud5putpjj.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
Message-ID: <17101.37403.452222.396424@montanaro.dyndns.org>


    >> I believe it's so that people can link in libraries written in C++
    >> and have them initialized properly.

    Dave> Can you give specifics?  What do you mean by "link in?"  Do you
    Dave> mean "statically link into the Python interpreter," or something
    Dave> else?

Probably not.  I'm not a C++ guy.  My understanding is that global (maybe
static?) C++ objects need the help of C++'s version of crt0 to get properly
initialized at program start.  If there is some library with such objects
that happens to get wrapped and dynamically linked into a Python interpreter
that was linked with a regular C linker (and thus had a C crt0), that
initialization wouldn't happen.

    Dave> Boost.Python is a library written in C++ and I've never had
    Dave> trouble using it with a Python executable... until I ran into a
    Dave> Python that was linked with libstdc++!

Sorry, I can't help.  I'm just recounting my remembering of the reasons for
C++ linkage.  Personally, I avoid C++ as much as I can...

Skip

From pje at telecommunity.com  Thu Jul  7 23:02:08 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 07 Jul 2005 17:02:08 -0400
Subject: [Python-Dev] Another SoC student for CVS access
In-Reply-To: <bbaeab1005070713306f1f34b5@mail.gmail.com>
Message-ID: <5.1.1.6.0.20050707170106.027e7970@mail.telecommunity.com>

At 01:30 PM 7/7/2005 -0700, Brett Cannon wrote:
>Floris is working on wrapping Hotshot to replace 'profile' and
>replacing pstats so that there will be no more need for 'profile' and
>thus take care of the licensing problem.  He also hopes to make pstats
>faster to use.  And if we are really lucky, get threading working for
>Hotshot.

Note that hotshot sometimes breaks inexplicably for traces that profile 
works fine on.  If you aren't certain you can fix this, removing the 
pure-Python profiler is not an option.


From walter at livinglogic.de  Thu Jul  7 23:31:35 2005
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 7 Jul 2005 23:31:35 +0200
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
In-Reply-To: <ca471dc205070711001297f0bf@mail.gmail.com>
References: <000001c58285$013a8200$2601a044@oemcomputer>
	<1120700091.23658.5.camel@geddy.wooz.org>
	<2mpstuvm0f.fsf@starship.python.net>
	<ca471dc205070711001297f0bf@mail.gmail.com>
Message-ID: <E47A1768-76DC-426B-83C6-BFA19D230EFC@livinglogic.de>


Am 07.07.2005 um 20:00 schrieb Guido van Rossum:

>>> +1 on @contextmanager
>
> +1.
>
> [__enter__, __exit__]
>
>>>> These names should be changed to __beginwith__ and __endwith__.
>>>>
>
> -1.  The PEP has had an extensive review period and several
> alternatives were discussed and rejected. These names are clear, they
> *do* match, and as Fred says the __*__ namespace has lots of room.
>
> Also, the PEP was accepted with these names. Now, if it was accepted
> with a major flaw or some semantics left unspecified,

What is still unspecified (or at least not explicitely mentioned) in  
the PEP is the lifetime of VAR in:

         with EXPR as VAR:
             BLOCK

Does VAR overwrite or shadow any previous values of VAR? I.e. will  
VAR still exist after the end of the block with its value the return  
value of __enter__() or will it revert to the previous value (if  
any)? I'd prefer the later although interpreting the translation of

         with EXPR as VAR:
             BLOCK

into

         abc = EXPR
         exc = (None, None, None)
         VAR = abc.__enter__()
         try:
             try:
                 BLOCK
             except:
                 exc = sys.exc_info()
                 raise
         finally:
             abc.__exit__(*exc)


literally would indicate the former.

Bye,
    Walter D?rwald


From martin at v.loewis.de  Fri Jul  8 00:01:56 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 08 Jul 2005 00:01:56 +0200
Subject: [Python-Dev] GCC version compatibility
In-Reply-To: <u8y0jz762.fsf@boost-consulting.com>
References: <u8y0jz762.fsf@boost-consulting.com>
Message-ID: <42CDA654.2080106@v.loewis.de>

David Abrahams wrote:
> I'm wondering if there has been a well-known recent change either in Python
> or GCC that would account for these new reports.  Any relevant
> information would be appreciated.

So what about the theory that it may be that different versions of
libstdc++ get linked? Python is linked with g++ if configure thinks
this is necessary, and the g++ used to link the extension might be
different.

I'd like to see a backtrace of one such mysterious crash.

Regards,
Martin

From martin at v.loewis.de  Fri Jul  8 00:13:13 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 08 Jul 2005 00:13:13 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <u64vmycwv.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>
Message-ID: <42CDA8F9.7080103@v.loewis.de>

David Abrahams wrote:
> Apparently Python on some linux distros is being linked by g++ rather
> than gcc, resulting in the C++ runtime library being linked into
> Python; this has bad consequences for compatibility between C++
> extension modules and Pythons that have been built with different
> versions of GCC.  Is this behavior intentional?

It's as Skip says. According to the C++ standard, a "C++ program" is
one where all translation units are written in C++. While most platforms
offer interoperability between C and C++ in the sense that C libraries
can be linked into C++ programs, interoperability in the other direction
is not always supported, i.e. C programs may not be able to use C++
libraries. This is the specific case you are talking about: Python is
written in C, yet the extension might be written in C++.

Now, on some of these implementations, things can be fixed by writing
main() as a C++ translation unit, and compiling it with the C++
compiler. Then, Python itself is a C library to this C++ program, and
the extension modules are C++ libraries. Then everything works fine.

To support this, main() must be a C++ program. Python compiles main
using the C++ compiler if configure thinks this is necessary.

Doing so is necessary for example on systems using the G++ collect2
mechanism for static initializers: compiling main with g++ leads
to a call to __main(), which is then created by collect2.

configure thinks that using CXX for linking is necessary if compiling
a program using CXX and linking it using CC fails.

Regards,
Martin

From gustavo at niemeyer.net  Fri Jul  8 00:15:26 2005
From: gustavo at niemeyer.net (Gustavo Niemeyer)
Date: Thu, 7 Jul 2005 19:15:26 -0300
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <bbaeab10050707132238085d24@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<1f7befae05070711484f214a4@mail.gmail.com>
	<ca471dc20507071154449e8dcd@mail.gmail.com>
	<1f7befae0507071217399243b4@mail.gmail.com>
	<bbaeab10050707132238085d24@mail.gmail.com>
Message-ID: <20050707221526.GA8015@burma.localdomain>

> > > How would a PEP to *remove* this feature fare today?

I hope not well, since I use them quite often.

> Barry also reiterated this idea and I support removing them in Python
> 3000.  I do use them when I want to know when I break out of a loop
> prematurely, but I am definitely not a typical use case for
> experienced users since I basically learned how to program in Python
> so I didn't have any baggage preventing me from not remembering they
> existed.

So you're indeed an example that learning them might not be
an issue, even when no previous programming experience exists.

For the case of an experienced programmer getting into Python
as a new language, most of us have been there, and I remember
that, when I understood what it was about, I was actually
amazed rather than confused. I started wondering why it's not
available in other languages.

> Simplifying the basic control flow mechanisms is always good.
[...]

Of course, it largely depends on what simplifying means to you.

As a side comment, I belive that talking often and at regular
intervals about builtins and syntax which may disappear from
the language in the next major version is not something good.

I understand that the next major is being seen as the place
to break legacy compatibility, but that's the kind of thing
that you (Guido) are aware that no comments besides personal
likes and dislikes will be raised. If you *really* want to
remove them (even though I strongly dislike the idea ;-),
decide it and get just half of the complaints, rather than
getting all of them and spreading FUD.

-- 
Gustavo Niemeyer
http://niemeyer.net

From dave at boost-consulting.com  Fri Jul  8 00:27:46 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 18:27:46 -0400
Subject: [Python-Dev] GCC version compatibility
In-Reply-To: <42CDA654.2080106@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Fri, 08 Jul 2005 00:01:56 +0200")
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
Message-ID: <uu0j6p7z1.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>> I'm wondering if there has been a well-known recent change either in Python
>> or GCC that would account for these new reports.  Any relevant
>> information would be appreciated.
>
> So what about the theory that it may be that different versions of
> libstdc++ get linked? 

That's been confirmed.

> Python is linked with g++ if configure thinks this is necessary

Right.  The question is, when should configure "think it's necessary?"

> and the g++ used to link the extension might be different.
>
> I'd like to see a backtrace of one such mysterious crash.

I don't have it, but ldd confirms that the crash happens when the
versions of libstdc++ in python and in the extension module are
different.  A C++ exception thrown from the extension module into the
Boost.Python library to which it is linked (both compiled and linked
with the same g++) without passing through any of Python's code (of
course) will cause a crash unless Python is using the same libstdc++
as everything else, or unless Python isn't linked with libstdc++.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From dave at boost-consulting.com  Fri Jul  8 00:32:26 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 18:32:26 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <17101.37403.452222.396424@montanaro.dyndns.org> (Skip
	Montanaro's message of "Thu, 7 Jul 2005 15:35:39 -0500")
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
Message-ID: <upstup7r9.fsf@boost-consulting.com>

Skip Montanaro <skip at pobox.com> writes:

>     >> I believe it's so that people can link in libraries written in C++
>     >> and have them initialized properly.
>
>     Dave> Can you give specifics?  What do you mean by "link in?"  Do you
>     Dave> mean "statically link into the Python interpreter," or something
>     Dave> else?
>
> Probably not.  I'm not a C++ guy.  My understanding is that global (maybe
> static?) C++ objects need the help of C++'s version of crt0 to get properly
> initialized at program start.  

Yes.

> If there is some library with such objects that happens to get
> wrapped and dynamically linked into a Python interpreter 

Whoa there.  How would that ever happen under ordinary circumstances?
Doesn't Python's makefile control what gets linked to Python?

> that was linked with a regular C linker (and thus had a C crt0),
> that initialization wouldn't happen.

Right, and linking would fail, IIRC.  It seems to me that if someone
decides to build a wacky Python executable that links in C++ code
directly, they can afford to use a configure option.  There's no need
to punish all the other writers of C++ extension modules out there by
tying the default build of Python to a particular version of
libstdc++.

>     Dave> Boost.Python is a library written in C++ and I've never had
>     Dave> trouble using it with a Python executable... until I ran into a
>     Dave> Python that was linked with libstdc++!
>
> Sorry, I can't help.  I'm just recounting my remembering of the
> reasons for C++ linkage.  Personally, I avoid C++ as much as I
> can...

If there's someone around here who is responsible for this change and
knows its real rationale, can (s)he please tell me what it is?  If
not, can we please change things back so Python doesn't get linked to
the C++ runtime by default?

Thanks,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From bcannon at gmail.com  Fri Jul  8 00:32:33 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 7 Jul 2005 15:32:33 -0700
Subject: [Python-Dev] Another SoC student for CVS access
In-Reply-To: <e8bf7a53050707133241583242@mail.gmail.com>
References: <bbaeab1005070713306f1f34b5@mail.gmail.com>
	<e8bf7a53050707133241583242@mail.gmail.com>
Message-ID: <bbaeab1005070715324a0d37a5@mail.gmail.com>

On 7/7/05, Jeremy Hylton <jhylton at gmail.com> wrote:
> On 7/7/05, Brett Cannon <bcannon at gmail.com> wrote:
> > Floris is working on wrapping Hotshot to replace 'profile' and
> > replacing pstats so that there will be no more need for 'profile' and
> > thus take care of the licensing problem.  He also hopes to make pstats
> > faster to use.  And if we are really lucky, get threading working for
> > Hotshot.
> 
> I don't think we actually want to get rid of profile and replace it
> with hotshot.  We want to have both tools available.
> 

This is mainly for backup if the original 'profile' is not available. 
Debian, for instance, leaves out 'profile' because of its licensing. 
I don't plan on removing 'profile' from CVS or anything.

-Brett

From jack at performancedrivers.com  Fri Jul  8 00:54:41 2005
From: jack at performancedrivers.com (Jack Diederich)
Date: Thu, 7 Jul 2005 18:54:41 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <5.1.1.6.0.20050707145039.0267e0c0@mail.telecommunity.com>
References: <ca471dc205070710484a5894c4@mail.gmail.com>
	<20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<5.1.1.6.0.20050707145039.0267e0c0@mail.telecommunity.com>
Message-ID: <20050707225441.GE9287@performancedrivers.com>

On Thu, Jul 07, 2005 at 03:03:35PM -0400, Phillip J. Eby wrote:
> At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
> >[Guido, on {for,while}/else]
> >...
> > > The question remains whether Python would be easier to learn without
> > > them. And if so, the question would remain whether that's offset by
> > > their utility for experienced developers. All hard to assess
> > > impartially!
> >
> >That's what I'm here for.  I like loop "else" clauses, but have to
> >admit that (a) I rarely use them; (b) most of the time I use them, my
> >control flow is on the way to becoming so convoluted that I'm going to
> >rewrite the whole function soon anyway;
> 
> Interesting; I usually intentionally write "else" clauses intending to 
> *clarify* the code.  That is, I often use it in cases where it's not 
> strictly necessary, e.g.:
> 
>     for thing in something:
>         if blah:
>             return thing
>     else:
>         return None
> 
> Because to me this clarifies that 'return None' is what happens if the loop 
> "fails".

I use else similarly, for defensive programming.

for (thing) in searchlist:
  if (matches(thing)):
    keeper = thing
    break
else:
  raise ValueError("No thing matches()")

I can't say I use it for much else, if I really want a default I do
found = None
for (thing) in searchlist:
  if (matches(thing)):
    found = None
    break

That could end with 'else: found = None' to assign a default but I like
the default to come first for readability.

-Jack

From barry at python.org  Fri Jul  8 01:17:55 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 07 Jul 2005 19:17:55 -0400
Subject: [Python-Dev] Another SoC student for CVS access
In-Reply-To: <bbaeab1005070713306f1f34b5@mail.gmail.com>
References: <bbaeab1005070713306f1f34b5@mail.gmail.com>
Message-ID: <1120778275.10494.49.camel@geddy.wooz.org>

On Thu, 2005-07-07 at 16:30, Brett Cannon wrote:
> Floris is working on wrapping Hotshot to replace 'profile' and
> replacing pstats so that there will be no more need for 'profile' and
> thus take care of the licensing problem.  He also hopes to make pstats
> faster to use.  And if we are really lucky, get threading working for
> Hotshot.

Speaking of hotshot, I think we may have fixed SF bug #900092.  I'm
going to upload a patch to that tracker item momentarily -- anyone care
to proof read it?  If so, let me know and I'll assign the issue to you
(or you can just take it).

We fixed it about 10 minutes ago and have only done minimal testing so
far, but I'm going to upload it anyway.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050707/58a0367f/attachment.pgp

From dave at boost-consulting.com  Fri Jul  8 02:27:25 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 07 Jul 2005 20:27:25 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42CDA8F9.7080103@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Fri, 08 Jul 2005 00:13:13 +0200")
References: <u64vmycwv.fsf@boost-consulting.com> <42CDA8F9.7080103@v.loewis.de>
Message-ID: <ufyuqp2fm.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>> Apparently Python on some linux distros is being linked by g++ rather
>> than gcc, resulting in the C++ runtime library being linked into
>> Python; this has bad consequences for compatibility between C++
>> extension modules and Pythons that have been built with different
>> versions of GCC.  Is this behavior intentional?
>
> It's as Skip says. According to the C++ standard, a "C++ program" is
> one where all translation units are written in C++. While most platforms
> offer interoperability between C and C++ in the sense that C libraries
> can be linked into C++ programs, interoperability in the other direction
> is not always supported, i.e. C programs may not be able to use C++
> libraries. This is the specific case you are talking about: Python is
> written in C, yet the extension might be written in C++.

The C++ standard doesn't cover interoperability with 'C', or dynamic
linking (we on the C++ committee are working to fix that, but for now
that is the case) and it doesn't cover dynamic loading without
linking, which is what happens when Python loads an extension written
in C++.  You can't appeal to the standard for the rules about what
needs to be done.  All this stuff is entirely
implementation-dependent.

> Now, on some of these implementations, things can be fixed by writing
> main() as a C++ translation unit, and compiling it with the C++
> compiler. Then, Python itself is a C library to this C++ program, and
> the extension modules are C++ libraries. Then everything works fine.

C++ extension modules work fine even when main() is a 'C' program on
Linux/GCC.  The only reason that main would have to be a C++ program
on this platform and compiler is if there were C++ translation units
_linked_ into it (not loaded as in with dlopen).  Since whoever writes
the Makefile for Python also controls what's being linked into it,
there's no reason to speculate and make Python a C++ program based on
what might be linked in.

> To support this, main() must be a C++ program. Python compiles main
> using the C++ compiler if configure thinks this is necessary.
>
> Doing so is necessary for example on systems using the G++ collect2
> mechanism for static initializers: compiling main with g++ leads
> to a call to __main(), which is then created by collect2.

Extension modules that get loaded with dlopen don't get their static
initializers run by __main() anyway.

> configure thinks that using CXX for linking is necessary if compiling
> a program using CXX and linking it using CC fails.

That might be the right thing to do for some programs, but AFAICT
that's the wrong logic to use for Python.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From thomas at thomas-lotze.de  Fri Jul  8 02:51:28 2005
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Fri, 8 Jul 2005 02:51:28 +0200
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <20050707225441.GE9287@performancedrivers.com>
References: <ca471dc205070710484a5894c4@mail.gmail.com>
	<20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<5.1.1.6.0.20050707145039.0267e0c0@mail.telecommunity.com>
	<20050707225441.GE9287@performancedrivers.com>
Message-ID: <20050708025128.7673ec29.thomas@thomas-lotze.de>

Jack Diederich <jack at performancedrivers.com> wrote:

> I can't say I use it for much else, if I really want a default I do
> found = None
> for (thing) in searchlist:
>   if (matches(thing)):
>     found = None
>     break
> 
> That could end with 'else: found = None' to assign a default but I
> like the default to come first for readability.

Actually I think assigning the fall-back value in an "else" branch is
more readable. To some extent it's just a feeling, but there's two
things: For one, it gives you all assignments to the result at closer,
if not the same, indentation levels. More importantly, the value is
unconditionally set by a single statement, namely the "for" construct,
instead of by either the first or both, the second assignment basically
making the first superfluous. Using "else" models better what you want
to do, IMO.

-- 

Viele Gr??e,
Thomas

From facundobatista at gmail.com  Fri Jul  8 03:32:30 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 7 Jul 2005 22:32:30 -0300
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <20050707221526.GA8015@burma.localdomain>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
	<1f7befae05070711484f214a4@mail.gmail.com>
	<ca471dc20507071154449e8dcd@mail.gmail.com>
	<1f7befae0507071217399243b4@mail.gmail.com>
	<bbaeab10050707132238085d24@mail.gmail.com>
	<20050707221526.GA8015@burma.localdomain>
Message-ID: <e04bdf3105070718322f225165@mail.gmail.com>

On 7/7/05, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:


> > Simplifying the basic control flow mechanisms is always good.
> [...]
> 
> Of course, it largely depends on what simplifying means to you.

If we lose the "else" in "for"s, we'd have to use a variable to mark
when we exit the normal way or we break it out.

Using another variable is something that complicates the reading of
the program: you see the new variable, have to discover to what it's
for, and to keep it in your mind while you follow the logic.

For me, simplifying means keeping the "else".

Just my Currency("0.02"), ;)

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From rrr at ronadam.com  Fri Jul  8 04:23:36 2005
From: rrr at ronadam.com (Ron Adam)
Date: Thu, 07 Jul 2005 22:23:36 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc2050707063938b19fb2@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>	<ca471dc2050706120231ecb092@mail.gmail.com>	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
Message-ID: <42CDE3A8.4050408@ronadam.com>

Guido van Rossum wrote:

> I even wonder if else-clauses on for/while were a good idea. (The one
> on try is definitely a good idea since the use case is quite frequent
> and only clumsily handled otherwise; the use cases for else on
> for/while are less convincing IMO.)


I'm +1 on removing the else from the loops myself.


The else's acts somewhat different depending on weather it's on an if, 
try, for, or while loop.  So it's four somewhat different behaviors for 
one keyword.

1. With an if, if you think in terms of flow testing you get the same 
results as if you look at it in in terms of value testing.  Either the 
if-block will execute or the else-block will, but never any part of one 
and then the other.  A binary solution to a binary problem.

2. With a try, It's a value test for no exception. Or you could consider 
it flow test for the try block completing.

3. In a while loop, it's a value test, where the else block gets 
executed if the while condition evaluates as false, the while block may 
or may not execute. You still need a flag to test for that.

4. In a for loop, it's a test of the iterator completing and generating 
a StopIteration exception.  Which is somewhat implicit.  The for block 
may or may not execute.


For Python 3000 it might be worth taking a look at flow control tests 
instead of value tests.

With loop flow control testing you have three possible values:

     None:  loop not started
     False: loop started but not completed, ie.. break
     True:  loop completed naturally

     * The current else behavior is an (if not False) test here.

I'm not sure how to test for the condition in a simple way. So it's 
still a -1 at this point.  <shrug>


As for elif...  it works for me. :)

Cheers,
Ron












From jepler at unpythonic.net  Fri Jul  8 05:17:09 2005
From: jepler at unpythonic.net (Jeff Epler)
Date: Thu, 7 Jul 2005 22:17:09 -0500
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <ufyuqp2fm.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com> <42CDA8F9.7080103@v.loewis.de>
	<ufyuqp2fm.fsf@boost-consulting.com>
Message-ID: <20050708031705.GA16279@unpythonic.net>

If we change the linker back to gcc, not g++, will it work if extension
module 1 gets linked with libstdc++ A and ABI Q, and extension module 2
gets linked with libstdc++ B and ABI Z?

What if a built-in module is written in C++, as it might be for some
people embedding C++? (this will force use of g++ as the linker, right?)

Don't these cases matter too?  Assuming they can fail now, how will
changing the use of CXX as the linker fix them?

Jeff
PS The Python 2.3 and Python 2.4 binaries installed on my Fedora Core
machine don't list libstdc++ in `rpm -q --requires python' or `ldd
/usr/bin/python'.  I don't see a patch that would change Python's
behavior in the SRPM, though.  I wonder what the difference is between
my FC2 and the other systems...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20050707/1ffe31bf/attachment.pgp

From dave at boost-consulting.com  Fri Jul  8 06:14:31 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Jul 2005 00:14:31 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <20050708031705.GA16279@unpythonic.net> (Jeff Epler's message of
	"Thu, 7 Jul 2005 22:17:09 -0500")
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CDA8F9.7080103@v.loewis.de> <ufyuqp2fm.fsf@boost-consulting.com>
	<20050708031705.GA16279@unpythonic.net>
Message-ID: <uu0j6lys8.fsf@boost-consulting.com>

Jeff Epler <jepler at unpythonic.net> writes:

> If we change the linker back to gcc, not g++, will it work if extension
> module 1 gets linked with libstdc++ A and ABI Q, and extension module 2
> gets linked with libstdc++ B and ABI Z?

Yes, unless they are using sys.setdlopenflags to force symbols to be
shared across these extension modules.  That's a very intentional act
and should (obviously?) only be undertaken when the extension modules
share an ABI.

> What if a built-in module is written in C++, as it might be for some
> people embedding C++? 

"Embedding" usually refers to embedding a _Python_ interpreter in a
program written in some language other than Python.  But I think
that's what you meant (just correct me if I'm wrong).

> (this will force use of g++ as the linker, right?)

Yes.

> Don't these cases matter too?  

Yes.  But the 2nd case is not one in which the Python executable is
being built.  The person building a program that embeds Python can
control how (s)he does linking.

> Assuming they can fail now, how will changing the use of CXX as the
> linker fix them?

I don't understand the question.

> Jeff
> PS The Python 2.3 and Python 2.4 binaries installed on my Fedora Core
> machine don't list libstdc++ in `rpm -q --requires python' or `ldd
> /usr/bin/python'.  I don't see a patch that would change Python's
> behavior in the SRPM, though.  I wonder what the difference is between
> my FC2 and the other systems...

I don't know; the ones we happen to be testing are Debian ("sarge," I
think).

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From bcannon at gmail.com  Fri Jul  8 06:19:05 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 7 Jul 2005 21:19:05 -0700
Subject: [Python-Dev] checklist for filing a bug
Message-ID: <bbaeab10050707211922059724@mail.gmail.com>

In order to lower the barrier for reporting bugs, writing patches, and
handling CVS commits, I am writing up checklists for each and I will
put them up on python.org.

The first checklist is for bug reports.  All comments welcome.  Keep
in mind the list is supposed to be short and straight-forward; too
wordy and people won't read it.

Reporting a Bug
+++++++++++++++
For technical question for any step listed, refer to the `dev FAQ`_.

#. Make sure the bug is reproducible
    The bug cannot be a freak occurence and must be reproducible so developers
    can test against it.
#. Isolate bug
    Come up with a code snippet that is as succinct as possible that triggers
    the bug consistently.  Coding it as a unit test is the best.
#. Gather important information
    Info such as Python version, operating system version, etc.; anything that
    might have influenced the code that lead to the bug.
#. Report the bug on SourceForge_
    Create a new tracker item, filling out the ``Category`` and ``Group``
    fields.  Do not set the ``Assigned To`` or ``Priority`` fields.  Upload  
    your code snippet as a file and make sure to click the ``Upload`` button! 


.. _dev FAQ: http://www.python.org/dev/devfaq.html
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470&atid=105470

From martin at v.loewis.de  Fri Jul  8 07:24:32 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 08 Jul 2005 07:24:32 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <ufyuqp2fm.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>	<42CDA8F9.7080103@v.loewis.de>
	<ufyuqp2fm.fsf@boost-consulting.com>
Message-ID: <42CE0E10.6080509@v.loewis.de>

David Abrahams wrote:
>>configure thinks that using CXX for linking is necessary if compiling
>>a program using CXX and linking it using CC fails.
> 
> 
> That might be the right thing to do for some programs, but AFAICT
> that's the wrong logic to use for Python.

Why do you say that? Python compiles Modules/ccpython.cc as the main
function, using the C++ compiler, and then tries to link it somehow.
On some systems (including some Linux installations), linking will
*fail* if linking is done using gcc (instead of g++). So we *must*
link using g++, or else it won't link at all.

Regards,
Martin

From martin at v.loewis.de  Fri Jul  8 07:31:41 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 08 Jul 2005 07:31:41 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <20050708031705.GA16279@unpythonic.net>
References: <u64vmycwv.fsf@boost-consulting.com> <42CDA8F9.7080103@v.loewis.de>
	<ufyuqp2fm.fsf@boost-consulting.com>
	<20050708031705.GA16279@unpythonic.net>
Message-ID: <42CE0FBD.3070209@v.loewis.de>

Jeff Epler wrote:
> If we change the linker back to gcc, not g++, will it work if extension
> module 1 gets linked with libstdc++ A and ABI Q, and extension module 2
> gets linked with libstdc++ B and ABI Z?

The problem is that it won't link at all. Compiling Modules/ccpython.o
using g++ creates (in some installations) a reference to libgcc
functions that won't be resolved unless you also link using g++. This
is because libgcc was split into two libraries, and only one of them
gets automatically linked when linking with gcc; the missing symbol
is in the other library which only gets linked automatically when
linking with g++.

> What if a built-in module is written in C++, as it might be for some
> people embedding C++? (this will force use of g++ as the linker, right?)

Right. If those people also use dynamic extensions, they should make
sure that those link against the same libstdc++.

> PS The Python 2.3 and Python 2.4 binaries installed on my Fedora Core
> machine don't list libstdc++ in `rpm -q --requires python' or `ldd
> /usr/bin/python'.  I don't see a patch that would change Python's
> behavior in the SRPM, though.  I wonder what the difference is between
> my FC2 and the other systems...

One solution/work-around is to configure Python with --without-cxx. Then
ccpython.cc won't be used, and all compiling and linking is done using
gcc. Whether or not this would still allow for extension modules to use
C++ depends on the platform; on Linux, it will.

I believe Linux distributors normally build Python with --without-cxx.

Regards,
Martin

From dave at boost-consulting.com  Fri Jul  8 07:49:23 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Jul 2005 01:49:23 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42CE0E10.6080509@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Fri, 08 Jul 2005 07:24:32 +0200")
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CDA8F9.7080103@v.loewis.de> <ufyuqp2fm.fsf@boost-consulting.com>
	<42CE0E10.6080509@v.loewis.de>
Message-ID: <upsttn8yk.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>>>configure thinks that using CXX for linking is necessary if compiling
>>>a program using CXX and linking it using CC fails.
>> 
>> 
>> That might be the right thing to do for some programs, but AFAICT
>> that's the wrong logic to use for Python.
>
> Why do you say that? Python compiles Modules/ccpython.cc as the main
> function, using the C++ compiler, and then tries to link it somehow.
> On some systems (including some Linux installations), linking will
> *fail* if linking is done using gcc (instead of g++). So we *must*
> link using g++, or else it won't link at all.

This is starting to feel tautological, or self-referential, or
something.  If by ccpython.cc you mean
http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Modules/ccpython.cc
well of *course* linking will fail.  You have to compile that file as
C++ program since it uses

    extern "C"

which is only legal in C++ .  But AFAICT, in a normal build of the
Python executable, there's no reason at all for main to be a C++
function in the first place.

Unless, of course, I'm missing something.  So if I am missing
something, what is it?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From tanzer at swing.co.at  Fri Jul  8 09:04:44 2005
From: tanzer at swing.co.at (tanzer@swing.co.at)
Date: Fri, 08 Jul 2005 09:04:44 +0200
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: Your message of "Thu, 07 Jul 2005 11:54:49 PDT."
	<ca471dc20507071154449e8dcd@mail.gmail.com> 
Message-ID: <E1Dqmui-000245-Qw@swing.co.at>

> > [Guido, on {for,while}/else]
> 
> How would a PEP to *remove* this feature fare today?

-1.

It took me a while (actually a *long* while) to start using else
clauses in loops, but I've learned to love them. Although there
aren't that many use cases, they make the code more readable (and
writable) where they apply.

For me, for/else and while/else didn't make Python harder to
learn; I just ignored them for some years.

And I'm horrified at the thought of having to go look for all
occurrences if they were removed (if Py3k ever happens, I'd hope
that it would be the *one* Python to use -- too many
incompatibilities would probably mean *two* Pythons fighting each
other).

-- 
Christian Tanzer                                    http://www.c-tanzer.at/


From gvanrossum at gmail.com  Fri Jul  8 09:53:14 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Fri, 8 Jul 2005 00:53:14 -0700
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
In-Reply-To: <E47A1768-76DC-426B-83C6-BFA19D230EFC@livinglogic.de>
References: <000001c58285$013a8200$2601a044@oemcomputer>
	<1120700091.23658.5.camel@geddy.wooz.org>
	<2mpstuvm0f.fsf@starship.python.net>
	<ca471dc205070711001297f0bf@mail.gmail.com>
	<E47A1768-76DC-426B-83C6-BFA19D230EFC@livinglogic.de>
Message-ID: <ca471dc2050708005314e8c498@mail.gmail.com>

On 7/7/05, Walter D?rwald <walter at livinglogic.de> wrote:
> What is still unspecified (or at least not explicitely mentioned) in
> the PEP is the lifetime of VAR in:
> 
>          with EXPR as VAR:
>              BLOCK

It is specified well enough IMO -- you're supposed to take the
translation into basic Python seriously. That translation specifies a
simple assignment to VAR, and that's what I meant (and what I'm sure
most folks understood). IOW VAR lives in the surrounding scope,
overwrites a previous value, and survives past the with-statement
(unless it is set inside of course).

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

From ncoghlan at gmail.com  Fri Jul  8 11:11:25 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 08 Jul 2005 19:11:25 +1000
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <5.1.1.6.0.20050707145039.0267e0c0@mail.telecommunity.com>
References: <ca471dc205070710484a5894c4@mail.gmail.com>	<20050706200745.22493ade.thomas@thomas-lotze.de>	<ca471dc2050706120231ecb092@mail.gmail.com>	<20050707103833.327547ed.thomas@thomas-lotze.de>	<ca471dc2050707063938b19fb2@mail.gmail.com>	<20050707163452.GA12703@phenix.progiciels-bpi.ca>	<ca471dc205070710484a5894c4@mail.gmail.com>
	<5.1.1.6.0.20050707145039.0267e0c0@mail.telecommunity.com>
Message-ID: <42CE433D.3040505@gmail.com>

Phillip J. Eby wrote:
> At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
>>I also suspect that if they weren't in the language already, a PEP to
>>introduce them would fail, because
>>
>>    still_looking = True
>>    some loop:
>>        if found it:
>>            still_looking = False
>>            break
>>    if still_looking:
>>        # what would have been in the "else" clause
>>
>>is clear and easy to write without it.
> 
> 
> *shudder* Okay, you just convinced me.  "Else" should stay, because the 
> above is much less readable and writable!

I think Aahz's point is a good one - conditional flow control can be most 
clearly represented using try blocks:

   class BreakException(Exception): pass

   try:
       some loop:
           if found it:
               raise BreakException
   except BreakException:
       pass
   else:
       # What would have been in the else clause

Defining 'else' on loops as short-hand for the above may make the intent of 
the clauses clearer (that is, for/else and while/else are more closely related 
to try statements than they are to if statements).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From thomas at thomas-lotze.de  Fri Jul  8 11:21:47 2005
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Fri, 8 Jul 2005 11:21:47 +0200
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <42CDE3A8.4050408@ronadam.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<42CDE3A8.4050408@ronadam.com>
Message-ID: <20050708112147.7233ad5a.thomas@thomas-lotze.de>

Ron Adam <rrr at ronadam.com> wrote:

> 1. With an if, if you think in terms of flow testing you get the same 
> results as if you look at it in in terms of value testing.  Either the
> if-block will execute or the else-block will, but never any part of
> one  and then the other.  A binary solution to a binary problem.
> 
> 2. With a try, It's a value test for no exception. Or you could
> consider  it flow test for the try block completing.

You might also look at it like this: There's a correspondence between
the if and try statements with if/elif corresponding to except and else
having the same meaning in both cases. With the exception of the try
suite that sets the stage for exception handlers, both statements give
you a set of branches (if/elif/else suites and execpt/else suites,
resp.) exactly one of which will execute.

Which is one of the reasons why I came to think of my proposal starting
this thread of being half-baked at best...

> 3. In a while loop, it's a value test, where the else block gets 
> executed if the while condition evaluates as false, the while block
> may  or may not execute. You still need a flag to test for that.

You're effectively arguing for do...while, right?

> 4. In a for loop, it's a test of the iterator completing and
> generating  a StopIteration exception.  Which is somewhat implicit. 
> The for block  may or may not execute.

This is something different IMO. You don't want to model condition
testing, you want to act on a set of values which may or may not be
empty. That's why I think you actually want the StopIteration stuff to
be implicit.

-- 

Viele Gr??e,
Thomas

From yess at hell.org.pl  Fri Jul  8 11:40:37 2005
From: yess at hell.org.pl (Tadeusz Andrzej =?iso-8859-2?Q?Kad=B3ubowski?=)
Date: Fri, 8 Jul 2005 11:40:37 +0200
Subject: [Python-Dev] checklist for filing a bug
In-Reply-To: <bbaeab10050707211922059724@mail.gmail.com>
References: <bbaeab10050707211922059724@mail.gmail.com>
Message-ID: <20050708094037.GA16266@hell.org.pl>

Thus wrote Brett Cannon:

How about:

> #. Report the bug on SourceForge_

      Make sure your bug hasn't been reported many times already.

>     Create a new tracker item, filling out the ``Category`` and ``Group``
>     fields.  Do not set the ``Assigned To`` or ``Priority`` fields.  Upload  
>     your code snippet as a file and make sure to click the ``Upload`` button! 

-- 
tadeusz andrzej kad?ubowski

From walter at livinglogic.de  Fri Jul  8 13:39:44 2005
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 08 Jul 2005 13:39:44 +0200
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <ca471dc2050708005314e8c498@mail.gmail.com>
References: <000001c58285$013a8200$2601a044@oemcomputer>	
	<1120700091.23658.5.camel@geddy.wooz.org>	
	<2mpstuvm0f.fsf@starship.python.net>	
	<ca471dc205070711001297f0bf@mail.gmail.com>	
	<E47A1768-76DC-426B-83C6-BFA19D230EFC@livinglogic.de>
	<ca471dc2050708005314e8c498@mail.gmail.com>
Message-ID: <42CE6600.6070700@livinglogic.de>

Guido van Rossum wrote:
> On 7/7/05, Walter D?rwald <walter at livinglogic.de> wrote:
> 
>>What is still unspecified (or at least not explicitely mentioned) in
>>the PEP is the lifetime of VAR in:
>>
>>         with EXPR as VAR:
>>             BLOCK
> 
> It is specified well enough IMO -- you're supposed to take the
> translation into basic Python seriously. That translation specifies a
> simple assignment to VAR, and that's what I meant (and what I'm sure
> most folks understood). IOW VAR lives in the surrounding scope,
> overwrites a previous value, and survives past the with-statement
> (unless it is set inside of course).

Are there use cases for both variants?

If VAR would live only until the end of the with block, this would give 
us a nice way of generating nested data structures:

class blist(list):
    def __init__(self, parent=None):
       if parent:
          parent.append(self)
       list.__init__(self)

    def __enter__(self):
       return self

    def __call__(self, *items):
       self.extend(items)
       return self

x = blist()
x(1)
with blist(x) as x:
    x(2)
    with blist(x) as x:
       x(3)
    x(4)
x(5)

This would create the list:
[1, [2, [3], 4], 5]

With the current version of PEP 343, we would either have to use 
different variable names on each level or use a global stack where 
__enter__() and __exit__() push and pop values.

Bye,
    Walter D?rwald

From mwh at python.net  Fri Jul  8 13:39:58 2005
From: mwh at python.net (Michael Hudson)
Date: Fri, 08 Jul 2005 12:39:58 +0100
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <E47A1768-76DC-426B-83C6-BFA19D230EFC@livinglogic.de> (
	=?iso-8859-1?q?Walter_D=F6rwald's_message_of?= "Thu, 7 Jul 2005 23:31:35
	+0200")
References: <000001c58285$013a8200$2601a044@oemcomputer>
	<1120700091.23658.5.camel@geddy.wooz.org>
	<2mpstuvm0f.fsf@starship.python.net>
	<ca471dc205070711001297f0bf@mail.gmail.com>
	<E47A1768-76DC-426B-83C6-BFA19D230EFC@livinglogic.de>
Message-ID: <2md5ptv84x.fsf@starship.python.net>

Walter D?rwald <walter at livinglogic.de> writes:

> Am 07.07.2005 um 20:00 schrieb Guido van Rossum:
>
>>>> +1 on @contextmanager
>>
>> +1.
>>
>> [__enter__, __exit__]
>>
>>>>> These names should be changed to __beginwith__ and __endwith__.
>>>>>
>>
>> -1.  The PEP has had an extensive review period and several
>> alternatives were discussed and rejected. These names are clear, they
>> *do* match, and as Fred says the __*__ namespace has lots of room.
>>
>> Also, the PEP was accepted with these names. Now, if it was accepted
>> with a major flaw or some semantics left unspecified,
>
> What is still unspecified (or at least not explicitely mentioned) in  
> the PEP is the lifetime of VAR in:
>
>          with EXPR as VAR:
>              BLOCK
>
> Does VAR overwrite or shadow any previous values of VAR? 

Yup!  Or at least in my half-an-implementation, that's what happens.

(PEP 343 is a lot harder to implement then you might think, btw -- the
stack discipline around finally: statements is a bit mind-bending).

> I.e. will VAR still exist after the end of the block with its value
> the return value of __enter__() or will it revert to the previous
> value (if any)?

Eh, no.  Where would you store the old value?

> I'd prefer the later although interpreting the translation of
>
>          with EXPR as VAR:
>              BLOCK
>
> into
>
>          abc = EXPR
>          exc = (None, None, None)
>          VAR = abc.__enter__()
>          try:
>              try:
>                  BLOCK
>              except:
>                  exc = sys.exc_info()
>                  raise
>          finally:
>              abc.__exit__(*exc)
>
>
> literally would indicate the former.

Please continue to interpret it like that :)

Cheers,
mwh

-- 
  > Why are we talking about bricks and concrete in a lisp newsgroup?
  After long experiment it was found preferable to talking about why
  Lisp is slower than C++...
                        -- Duane Rettig & Tim Bradshaw, comp.lang.lisp

From walter at livinglogic.de  Fri Jul  8 13:48:27 2005
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 08 Jul 2005 13:48:27 +0200
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <2md5ptv84x.fsf@starship.python.net>
References: <000001c58285$013a8200$2601a044@oemcomputer>	<1120700091.23658.5.camel@geddy.wooz.org>	<2mpstuvm0f.fsf@starship.python.net>	<ca471dc205070711001297f0bf@mail.gmail.com>	<E47A1768-76DC-426B-83C6-BFA19D230EFC@livinglogic.de>
	<2md5ptv84x.fsf@starship.python.net>
Message-ID: <42CE680B.108@livinglogic.de>

Michael Hudson wrote:

> Walter D?rwald <walter at livinglogic.de> writes:
> [...]
>>I.e. will VAR still exist after the end of the block with its value
>>the return value of __enter__() or will it revert to the previous
>>value (if any)?
> 
> Eh, no.  Where would you store the old value?

I don't know, where does:

 >>> x = 42
 >>> "".join(chr(x) for x in xrange(10))
'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t'
 >>> x
42

store it?

 > [...]

Bye,
    Walter D?rwald

From mwh at python.net  Fri Jul  8 13:57:28 2005
From: mwh at python.net (Michael Hudson)
Date: Fri, 08 Jul 2005 12:57:28 +0100
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42CE680B.108@livinglogic.de> (
	=?iso-8859-1?q?Walter_D=F6rwald's_message_of?= "Fri,
	08 Jul 2005 13:48:27 +0200")
References: <000001c58285$013a8200$2601a044@oemcomputer>
	<1120700091.23658.5.camel@geddy.wooz.org>
	<2mpstuvm0f.fsf@starship.python.net>
	<ca471dc205070711001297f0bf@mail.gmail.com>
	<E47A1768-76DC-426B-83C6-BFA19D230EFC@livinglogic.de>
	<2md5ptv84x.fsf@starship.python.net> <42CE680B.108@livinglogic.de>
Message-ID: <2m8y0hv7br.fsf@starship.python.net>

Walter D?rwald <walter at livinglogic.de> writes:

> Michael Hudson wrote:
>
>> Walter D?rwald <walter at livinglogic.de> writes:
>> [...]
>>>I.e. will VAR still exist after the end of the block with its value
>>>the return value of __enter__() or will it revert to the previous
>>>value (if any)?
>> 
>> Eh, no.  Where would you store the old value?
>
> I don't know, where does:
>
>  >>> x = 42
>  >>> "".join(chr(x) for x in xrange(10))
> '\x00\x01\x02\x03\x04\x05\x06\x07\x08\t'
>  >>> x
> 42
>
> store it?

In a new frame, AIUI.

You'll get a different answer for a list comprehension, as I'm sure
you know.

Cheers,
mwh

-- 
  I sense much distrust in you.  Distrust leads to cynicism, cynicism
  leads to bitterness, bitterness leads to the Awareness Of True
  Reality which is referred to by those-who-lack-enlightenment as
  "paranoia".  I approve.    -- David P. Murphy, alt.sysadmin.recovery

From mwh at python.net  Fri Jul  8 14:01:16 2005
From: mwh at python.net (Michael Hudson)
Date: Fri, 08 Jul 2005 13:01:16 +0100
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <42CDE3A8.4050408@ronadam.com> (Ron Adam's message of "Thu, 07
	Jul 2005 22:23:36 -0400")
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<42CDE3A8.4050408@ronadam.com>
Message-ID: <2m4qb5v75f.fsf@starship.python.net>

Ron Adam <rrr at ronadam.com> writes:

> Guido van Rossum wrote:
>
>> I even wonder if else-clauses on for/while were a good idea. (The one
>> on try is definitely a good idea since the use case is quite frequent
>> and only clumsily handled otherwise; the use cases for else on
>> for/while are less convincing IMO.)
>
>
> I'm +1 on removing the else from the loops myself.

... in Python 3000, I hope you meant to qualify that with.

Cheers,
mwh

-- 
  <foom> wait when was the earth created?
  <flophouse> just look at the expiration date
  <flophouse> it's on the bottom, under the ice cap
                                                -- from Twisted.Quotes

From nyamatongwe at gmail.com  Fri Jul  8 14:43:41 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Fri, 8 Jul 2005 22:43:41 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <y88j3pqo.fsf@python.net>
References: <d9mmd6$gjf$1@sea.gmane.org> <d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
	<ca471dc2050703112845321ad3@mail.gmail.com>
	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<50862ebd05070604117e9c5fb4@mail.gmail.com> <y88j3pqo.fsf@python.net>
Message-ID: <50862ebd05070805431808b7e5@mail.gmail.com>

Thomas Heller:

> OTOH, I once had a bug report from a py2exe user who complained that the
> program didn't start when installed in a path with japanese characters
> on it.  I tried this out, the bug existed (and still exists), but I was
> astonished how many programs behaved the same: On a PC with english
> language settings, you cannot start WinZip or Acrobat Reader (to give
> just some examples) on a .zip or .pdf file contained in such a
> directory.

   Much of the time these sorts of bugs don't make themselves too hard
to live with because  most non-ASCII names that any user encounters
are still in the user's locale and so get mapped by Windows. It can be
a lot of work supporting wide file names. I have just added wide file
name support to my editor, SciTE, for the second time and am about to
rip it out again as it complicates too much code for too few
beneficiaries. (I want one executable for both Windows NT+ and 9x, so
wide file names has to be a runtime choice leading to maybe 50 new
branches in the code).

   If returning a mixture of unicode and narrow strings from
os.listdir is the right thing to do then maybe it better for sys.argv
and os.environ to also be mixtures. In patch #1231336 I added parallel
attributes, sys.argvu and os.environu to hold unicode versions of this
information. The alternative, placing unicode items in the existing
attributes minimises API size.

   One question here is whether unicode items should be added only
when the element is outside the user's locale (the CP_ACP code page)
or whenever the item is outside ASCII. The former is more similar to
existing behaviour but the latter is safer as it makes it harder to
implicitly treat the data as being in an incorrect encoding.

   Neil

From skip at pobox.com  Fri Jul  8 14:55:40 2005
From: skip at pobox.com (Skip Montanaro)
Date: Fri, 8 Jul 2005 07:55:40 -0500
Subject: [Python-Dev] checklist for filing a bug
In-Reply-To: <bbaeab10050707211922059724@mail.gmail.com>
References: <bbaeab10050707211922059724@mail.gmail.com>
Message-ID: <17102.30668.172137.619995@montanaro.dyndns.org>

    Brett> #. Gather important information
    Brett>     Info such as Python version, operating system version, etc.;
    Brett>     anything that might have influenced the code that lead to the
    Brett>     bug.

I'd change this to something more explicit:

    # Gather important information
      * Python version
      * Operating system and version
      * Third-party modules installed/involved
      * Presence of user-written extension modules
      ... add your own faves here ...

I doubt that a wet-behind-the-ears Python programmer who only knows Windows
is likely to understand that Windows XP Home Edition (vs. CentOS 4) might be
a factor in the emergence of the bug.

Skip


From ncoghlan at gmail.com  Fri Jul  8 16:21:35 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 09 Jul 2005 00:21:35 +1000
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <5.1.1.6.0.20050707141420.02674e58@mail.telecommunity.com>
References: <42C91A07.9030402@gmail.com>
	<000701c57e8f$86c35ae0$aa36c797@oemcomputer>
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>
	<42C91A07.9030402@gmail.com>
	<5.1.1.6.0.20050707141420.02674e58@mail.telecommunity.com>
Message-ID: <42CE8BEF.9050508@gmail.com>

Phillip J. Eby wrote:
> I suggest changing this to something like this:
> 
>     class tag(object):
>         def __init__(self,name):
>             self.name = name
>         def __enter__(self):
>             print "<%s>" % name
>         def __exit__(self):
>             print "</%s>" % name
> 
>     with tag('html'):
>         # ... etc.
> 
> So that it's obvious where the implementation is coming from.  
> Otherwise, it looks altogether too magical.

Done - included in the latest version on SF. [1]

> Also, the posted draft doesn't explain what happens to the __enter__ 
> return value, either in a literal sense or in the sense of where it fits 
> in the overall concept of context management.

I've tried to clarify this by showing usage of the closing() context manager.

Cheers,
Nick.

[1] http://www.python.org/sf/1234057

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From theller at python.net  Fri Jul  8 16:48:04 2005
From: theller at python.net (Thomas Heller)
Date: Fri, 08 Jul 2005 16:48:04 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
 review)
In-Reply-To: <50862ebd05070805431808b7e5@mail.gmail.com> (Neil Hodgson's
	message of "Fri, 8 Jul 2005 22:43:41 +1000")
References: <d9mmd6$gjf$1@sea.gmane.org> <d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
	<ca471dc2050703112845321ad3@mail.gmail.com>
	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<50862ebd05070604117e9c5fb4@mail.gmail.com> <y88j3pqo.fsf@python.net>
	<50862ebd05070805431808b7e5@mail.gmail.com>
Message-ID: <wto1wdzv.fsf@python.net>

Neil Hodgson <nyamatongwe at gmail.com> writes:

> Thomas Heller:
>
>> OTOH, I once had a bug report from a py2exe user who complained that the
>> program didn't start when installed in a path with japanese characters
>> on it.  I tried this out, the bug existed (and still exists), but I was
>> astonished how many programs behaved the same: On a PC with english
>> language settings, you cannot start WinZip or Acrobat Reader (to give
>> just some examples) on a .zip or .pdf file contained in such a
>> directory.
>
>    Much of the time these sorts of bugs don't make themselves too hard
> to live with because  most non-ASCII names that any user encounters
> are still in the user's locale and so get mapped by Windows.

> It can be a lot of work supporting wide file names. I have just added
> wide file name support to my editor, SciTE, for the second time and am
> about to rip it out again as it complicates too much code for too few
> beneficiaries. (I want one executable for both Windows NT+ and 9x, so
> wide file names has to be a runtime choice leading to maybe 50 new
> branches in the code).

In python, the basic support for unicode file and pathnames is already
there.  No problem to open a file named
u'\u5b66\u6821\u30c7\u30fc\\blah.py on WinXP with german locale.

But adding u'\u5b66\u6821\u30c7\u30fc' to sys.path won't allow to import
this file as module.  Internally Python\import.c converts everything to
strings.  I started to refactor import.c to work with PyStringObjects
instead of char buffers as a first step - PyUnicodeObjects could have
been added later, but I gave up because there seems absolute zero
interest in it.

Ok - it makes no sense to have Python modules in directories with these
filenames, but Python (especially when frozen or py2exe'd) itself could
easily live itself in such a directory.

>    If returning a mixture of unicode and narrow strings from
> os.listdir is the right thing to do then maybe it better for sys.argv
> and os.environ to also be mixtures. In patch #1231336 I added parallel
> attributes, sys.argvu and os.environu to hold unicode versions of this
> information. The alternative, placing unicode items in the existing
> attributes minimises API size.
>
>    One question here is whether unicode items should be added only
> when the element is outside the user's locale (the CP_ACP code page)
> or whenever the item is outside ASCII. The former is more similar to
> existing behaviour but the latter is safer as it makes it harder to
> implicitly treat the data as being in an incorrect encoding.

I can't judge on this - but it's easy to experiment with it, even in
current Python releases since sys.argvu, os.environu can also be
provided by extension modules.

But thanks that you care about this stuff - I'm a little bit worried
because all the other folks seem to think everything's ok (?).

Thomas


From dave at boost-consulting.com  Fri Jul  8 17:15:57 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Jul 2005 11:15:57 -0400
Subject: [Python-Dev] GCC version compatibility
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <u8y0hl45u.fsf@boost-consulting.com>


[Christoph, please keep the python-dev list in the loop here, at least
until they get annoyed and decide we're off-topic.  I think this is
crucial to the way they package and deliver Python]

Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:

> On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams wrote:
>> "Martin v. L?wis" <martin at v.loewis.de> writes:
>> 
>> > David Abrahams wrote:
>> >> I'm wondering if there has been a well-known recent change either in Python
>> >> or GCC that would account for these new reports.  Any relevant
>> >> information would be appreciated.
> [...]
>> > Python is linked with g++ if configure thinks this is necessary
>> 
>> Right.  The question is, when should configure "think it's necessary?"
>
> Just to add to the confusion... I encountered the case that configure decided
> to use gcc for linking but it should have used g++. (It is Python 
> PR #1189330 <http://tinyurl.com/dlheb>. This was on a x86 Linux system with
> g++ 3.4.2.)
>
> Background: The description of --with-cxx in the README of the
> Python 2.4.1 source distribution made me think that I need to
> configure my Python installation with
> --with-configure=/opt/gcc/gcc-3.4.2/bin/g++ if I plan to use C++
> extensions built with this compiler. (That was possibly a
> misunderstanding on my part, 

AFAICT, yes.

> but Python should build with this option anyway.)
>
> configure set `LINKCC=$(PURIFY) $(CC)'. The result was that make failed when
> linking the python executable due to an unresolved reference to
> __gxx_personality_v0. I had to replace CC by CXX in the definition of LINKCC
> to finish the build of Python.
>
> When I looked into this problem I saw that configure in fact builds a test
> executable that included an object file compiled with g++. If the link step
> with gcc succeeds then LINKCC is set as above, otherwise CXX is
> used. Obviously, on my system this test was successful so configure decided
> to link with gcc. However, minimal changes to the source of the test program
> caused the link step to fail. It was not obvious to me at all why the latter
> source code should cause a dependency on the C++ runtime if the original
> code does not. My conclusion was that this test is fragile and should be
> skipped. 

Sounds like it.  I have never understood what the test was really
checking for since the moment it was first described to me, FWIW.

> If Python is built with --with-cxx then it should be linked with CXX
> as well.

U betcha.

> I gather from posts on the Boost mailing lists that you can import
> Boost.Python extensions even if Python was configured
> --without-cxx. 

Yes, all the tests are passing that way.

> (On ELF based Linux/x86, at least.) That leaves me wondering
>
>  * when is --with-cxx really necessary?

I think it's plausible that if you set sys.dlopenflags to share
symbols it *might* end up being necessary, but IIRC Ralf does use
sys.dlopenflags with a standard build of Python (no
--with-cxx)... right, Ralf?

>  * what happens if I import extensions built with different g++ versions? Will
>    there be a conflict between the different versions of libstdc++ those
>    extensions depend on?

Not unless you set sys.dlopenflags to share symbols.  

It's conceivable that they might conflict through their shared use of
libboost_python.so, but I think you have to accept that an extension
module and the libboost_python.so it is linked with have to be built
with compatible ABIs anyway.  So in that case you may need to make
sure each group of extensions built with a given ABI use their own
libboost_python.so (or just link statically to libboost_python.a if
you don't need cross-module conversions).

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


From Scott.Daniels at Acm.Org  Fri Jul  8 18:35:26 2005
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Fri, 08 Jul 2005 09:35:26 -0700
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <E1Dqmui-000245-Qw@swing.co.at>
References: <ca471dc20507071154449e8dcd@mail.gmail.com>
	<E1Dqmui-000245-Qw@swing.co.at>
Message-ID: <dama0e$r0b$1@sea.gmane.org>

tanzer at swing.co.at wrote:
>... if Py3k ever happens, I'd hope that it would be the *one* Python
> to use -- too many incompatibilities would probably mean *two* 
> Pythons fighting each other).

A caduceus to heal software problems?

     http://www.pantheon.org/articles/c/caduceus.html

--Scott David Daniels
Scott.Daniels at Acm.Org


From anthony at interlink.com.au  Fri Jul  8 19:34:45 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sat, 9 Jul 2005 03:34:45 +1000
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc20507071154449e8dcd@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<1f7befae05070711484f214a4@mail.gmail.com>
	<ca471dc20507071154449e8dcd@mail.gmail.com>
Message-ID: <200507090334.46832.anthony@interlink.com.au>

On Friday 08 July 2005 04:54, Guido van Rossum wrote:
> How would a PEP to *remove* this feature fare today?

I'd very much prefer that we kept them. I find it a useful
way to group the behaviour of the looping - this bit is
the normal loop, and this bit at the end is when the loop
fails/is exhausted. This is obviously for when you use it in 
a loop where you're looking for a certain result. And yes, 
you can do something similar with try/except, but I find 
that ugly - 'break' is the natural way to get out of a loop, 
not 'raise'. I find using exceptions in this way to be a
sort of horrible goto-hack, and makes the code hard on the
brain. 

(obdisclaimer: for/else gets a mention in my OSCON python
tutorial, so I'd appreciate it if you _don't_ rip it out
in the next month <wink>)

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

From rrr at ronadam.com  Fri Jul  8 19:48:37 2005
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 08 Jul 2005 13:48:37 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <2m4qb5v75f.fsf@starship.python.net>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>	<ca471dc2050706120231ecb092@mail.gmail.com>	<20050707103833.327547ed.thomas@thomas-lotze.de>	<ca471dc2050707063938b19fb2@mail.gmail.com>	<42CDE3A8.4050408@ronadam.com>
	<2m4qb5v75f.fsf@starship.python.net>
Message-ID: <42CEBC75.4080506@ronadam.com>

Michael Hudson wrote:
> Ron Adam <rrr at ronadam.com> writes:
> 
> 
>>Guido van Rossum wrote:
>>
>>
>>>I even wonder if else-clauses on for/while were a good idea. (The one
>>>on try is definitely a good idea since the use case is quite frequent
>>>and only clumsily handled otherwise; the use cases for else on
>>>for/while are less convincing IMO.)
>>
>>
>>I'm +1 on removing the else from the loops myself.
> 
> 
> ... in Python 3000, I hope you meant to qualify that with.

Yes, that's what I meant.


> Cheers,
> mwh

From tjreedy at udel.edu  Fri Jul  8 19:58:27 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 8 Jul 2005 13:58:27 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
References: <000001c58285$013a8200$2601a044@oemcomputer>	<1120700091.23658.5.camel@geddy.wooz.org>	<2mpstuvm0f.fsf@starship.python.net>	<ca471dc205070711001297f0bf@mail.gmail.com>	<E47A1768-76DC-426B-83C6-BFA19D230EFC@livinglogic.de><ca471dc2050708005314e8c498@mail.gmail.com>
	<42CE6600.6070700@livinglogic.de>
Message-ID: <dames4$9uh$1@sea.gmane.org>


"Walter Dörwald" <walter at livinglogic.de> wrote in message 
news:42CE6600.6070700 at livinglogic.de...
>x = blist()
>x(1)
>with blist(x) as x:
>    x(2)
>    with blist(x) as x:
>       x(3)
>    x(4)
>x(5)

>This would create the list:
>[1, [2, [3], 4], 5]

>With the current version of PEP 343, we would either have to use
>different variable names on each level

To me, different  names on each level -- x0, x1, x2, ... would be clearer 
and preferable, so I would know right off which level something was being 
put at.

This is no different from using differnt iteration variables -- i,j,k; or 
i1, i2, i3; etc -- with nested loops.  In both cases, you can delete the 
unneeded var if you really care and will not be using them again for 
another nested construct.

Terry J. Reedy




From rrr at ronadam.com  Fri Jul  8 20:22:29 2005
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 08 Jul 2005 14:22:29 -0400
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <20050708112147.7233ad5a.thomas@thomas-lotze.de>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>	<ca471dc2050706120231ecb092@mail.gmail.com>	<20050707103833.327547ed.thomas@thomas-lotze.de>	<ca471dc2050707063938b19fb2@mail.gmail.com>	<42CDE3A8.4050408@ronadam.com>
	<20050708112147.7233ad5a.thomas@thomas-lotze.de>
Message-ID: <42CEC465.6070609@ronadam.com>

Thomas Lotze wrote:

> Ron Adam <rrr at ronadam.com> wrote:

>>3. In a while loop, it's a value test, where the else block gets 
>>executed if the while condition evaluates as false, the while block
>>may  or may not execute. You still need a flag to test for that.
> 
> 
> You're effectively arguing for do...while, right?

Not arguing anything.  Do-whiles are a flow control issue rather than a 
flow testing issue.   A differnt problem.

Cheers,
Ron


From tjreedy at udel.edu  Fri Jul  8 20:28:11 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 8 Jul 2005 14:28:11 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
References: <42C91A07.9030402@gmail.com><000701c57e8f$86c35ae0$aa36c797@oemcomputer><42C75006.6090902@ronadam.com>
	<42C7E146.4090403@gmail.com><42C91A07.9030402@gmail.com><5.1.1.6.0.20050707141420.02674e58@mail.telecommunity.com>
	<42CE8BEF.9050508@gmail.com>
Message-ID: <damgjs$fbt$1@sea.gmane.org>


"Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
news:42CE8BEF.9050508 at gmail.com...
> Phillip J. Eby wrote:
>> I suggest changing this to something like this:
>>
>>     class tag(object):
>>         def __init__(self,name):
>>             self.name = name
>>         def __enter__(self):
>>             print "<%s>" % name
>>         def __exit__(self):
>>             print "</%s>" % name
>>
>>     with tag('html'):
>>         # ... etc.
>>
>> So that it's obvious where the implementation is coming from.
>> Otherwise, it looks altogether too magical.
>
> Done - included in the latest version on SF. [1]

Would this also work as a decorated generator?
(If I have understood correctly, something like..)

@contextmanager
def tag(name)
       print "<%s>" % name
       yield None
       print "</%s>" % name

If so, I suggest putting in both versions to make the correspondence clear.

To whoever invented this example: thanks.  It rang a bell with me so I 
could see this as a generally usefully feature rather than a specialized 
(though for some, important) 'close resource' feature.

The particularly neat thing is that it converts the indent-dedent method of 
showing structure to the alternative matched-fences method.   This is 
certainly not limited to HTML generation.

Terry J. Reedy




From reinhold-birkenfeld-nospam at wolke7.net  Fri Jul  8 22:24:30 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Fri, 08 Jul 2005 22:24:30 +0200
Subject: [Python-Dev] Possible context managers in stdlib
Message-ID: <damndu$3fk$1@sea.gmane.org>

Hi,

I compiled a list of some possible new context managers that could be
added to the stdlib. Introducing a new feature should IMO also show
usage of it in the distribution itself. That wasn't done with
decorators (a decorators module is compiled at the moment, if I'm right),
but with context managers, there's certainly room to add some. Of course,
my list is excessive, it's only some ideas I got by flying over the stdlib
docs.

* builtins: with open/file
* sys: with sys.redirected_std[in|out|err]
       with sys.trace
       with sys.excepthook
* warnings: with warnings.filter
* pprint: with pprint.printer (used for print)
* codecs: with codecs.open
          with codecs.EncodedFile
* decimal: with decimal.Context
* os: with os.current_directory
      with os.modified_env
      with os.umask/uid/gid etc.
      with os.popen
      with os.tmpfile
* subprocess: with subprocess.Popen
* mutex: with mutexobj
* curses: with curses.wrapper
* tempfile: with tempfile.[Named]TemporaryFile
            etc.
* locale: with locale.differentlocale
* logging: with logging.ignored
           with logging.Logger
* signal: with signal.handler
* socket: with socket.socket
* threading: with threading.Lock
             with threading.Condition
             with threading.Event
* mmap: with mmap.mmap
* bz2/zipfile/tarfile: with ...open
* dl: with dl.open
* tty: with tty.raw
       with tty.cbreak
* cgitb: with cgitb.enabled
* urllib/urllib2: with urllib.urlopen
                  etc.
* httplib: with httplib.HTTPConnection
* ftplib: with ftplib.FTP
* poplib: with poplib.POP3
* imaplib: with imaplib.IMAP4
* nttplib: with nntplib.NNTP
* smtplib: with smtplib.SMTP
* telnetlib: with telnetlib.Telnet
* xmlrpclib: with xmlrpclib.ServerProxy

Reinhold

-- 
Mail address is perfectly valid!


From bcannon at gmail.com  Fri Jul  8 22:46:19 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Fri, 8 Jul 2005 13:46:19 -0700
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <damndu$3fk$1@sea.gmane.org>
References: <damndu$3fk$1@sea.gmane.org>
Message-ID: <bbaeab100507081346e0676dd@mail.gmail.com>

On 7/8/05, Reinhold Birkenfeld <reinhold-birkenfeld-nospam at wolke7.net> wrote:
> Hi,
> 
> I compiled a list of some possible new context managers that could be
> added to the stdlib. Introducing a new feature should IMO also show
> usage of it in the distribution itself. That wasn't done with
> decorators (a decorators module is compiled at the moment, if I'm right),
> but with context managers, there's certainly room to add some. Of course,
> my list is excessive, it's only some ideas I got by flying over the stdlib
> docs.
> 

I think that is a good point about decorators.  While none of us
obviously had extensive experience with decorators when they went into
the language we at least knew of a couple use cases that would have
been handy and it probably would have been good to have examples for
people to work off of.  I bet iterators have gotten more play thanks
to itertools and all of the built-ins that work with them.

I think having basic context managers in a stdlib module that we know
for a fact that will be handy is a good idea.  We should keep the list
short and poignant, but we should have something for people to work
off of.  The ones I like below for a 'context' module are:

> * builtins: with open/file
> * sys: with sys.redirected_std[in|out|err]
> * decimal: with decimal.Context
> * os: with os.current_directory
> * mutex: with mutexobj
> * threading: with threading.Lock
>              with threading.Condition
>              with threading.Event
> * bz2/zipfile/tarfile: with ...open

-Brett

From python at rcn.com  Fri Jul  8 22:53:58 2005
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 8 Jul 2005 16:53:58 -0400
Subject: [Python-Dev] checklist for filing a bug
In-Reply-To: <bbaeab10050707211922059724@mail.gmail.com>
Message-ID: <000f01c583ff$2a15d460$b432c797@oemcomputer>

> In order to lower the barrier for reporting bugs, writing patches, and
> handling CVS commits, I am writing up checklists for each and I will
> put them up on python.org.

-0 on the checklists.  I don't think existing "barriers" are high at
all.  The entries may be variously regarded as codifying common sense or
listing nice-to-haves instead of must haves.  Based on the SF activity
over the last few years, I conclude that the checklists attempt to solve
a non-problem (or rather a very minor irritant).

Yes, it would be great if everyone searched SF for all previous related
bug reports, and spent time isolating/reproducing the cause, and if all
bug reports were reproducible 100% of the time, and if someone wrote a
unittest for it.  Heck, it would be nicer still if they debugged the
exact problem and fixed it ;-)  However, in real life, we get plenty of
useful reports that don't fit one or all of those criteria.  I don't
want to unnecessarily raise the bar and not have someone report a
potentially valid bug.

IMO, the proposal is administrivia that doesn't add value and possibly
makes things worse (by causing some folks to not go through the hassle
of filing a report).


Raymond

From pje at telecommunity.com  Fri Jul  8 23:02:33 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 08 Jul 2005 17:02:33 -0400
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <damndu$3fk$1@sea.gmane.org>
Message-ID: <5.1.1.6.0.20050708165243.02689838@mail.telecommunity.com>

At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>        with sys.trace

Note that it's currently not possible to inspect the trace/profile hooks 
from Python code, only from C, so that might be, um, interesting to implement.

>* pprint: with pprint.printer (used for print)

Interesting; I'm not sure if I like it.

>* os: with os.current_directory

What does this do?  Oh, I get it.  The name's not very obvious.  I would've 
expected a more imperative name, something like 'with os.setcwd()' or 'with 
os.pushdir()'.

>       with os.modified_env
>       with os.umask/uid/gid etc.

Yeah, again I would expect more verbish names, but these are at least 
easier to grasp than current_directory was.


>* curses: with curses.wrapper
>            with logging.Logger
>* tty: with tty.raw
>        with tty.cbreak
>* cgitb: with cgitb.enabled

What do these do?


From foom at fuhm.net  Fri Jul  8 23:11:10 2005
From: foom at fuhm.net (James Y Knight)
Date: Fri, 8 Jul 2005 17:11:10 -0400
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <bbaeab100507081346e0676dd@mail.gmail.com>
References: <damndu$3fk$1@sea.gmane.org>
	<bbaeab100507081346e0676dd@mail.gmail.com>
Message-ID: <5DFC492F-2A4D-4926-926D-6F74B48FA516@fuhm.net>

On Jul 8, 2005, at 4:46 PM, Brett Cannon wrote:
> I think having basic context managers in a stdlib module that we know
> for a fact that will be handy is a good idea.  We should keep the list
> short and poignant, but we should have something for people to work
> off of.  The ones I like below for a 'context' module are:
>
>> * builtins: with open/file
>> * sys: with sys.redirected_std[in|out|err]
>> * decimal: with decimal.Context
>> * os: with os.current_directory
>> * mutex: with mutexobj
>> * threading: with threading.Lock
>>              with threading.Condition
>>              with threading.Event
>> * bz2/zipfile/tarfile: with ...open

It is a really bad idea to codify the practice of modifying non- 
threadlocal global state like sys.std[in|out|err] and current  
directory with a context manager. A user can do it to themselves now,  
true, but by putting a context manager for it in the stdlib, you make  
it look like it'd be a local modification when it is not. I can only  
see confusion resulting from this. Users will inevitably try to use  
it like
   with sys.redirected_stderr(f):
     print "hello"
     print "there"
instead of explicitly writing to f with print>> or write(). And that  
is just a terribly bad idea. It looks pretty, yes, but unless  
stdinouterr are made thread-local, it's just asking for trouble.

James

From barry at python.org  Fri Jul  8 23:19:28 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 08 Jul 2005 17:19:28 -0400
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <damndu$3fk$1@sea.gmane.org>
References: <damndu$3fk$1@sea.gmane.org>
Message-ID: <1120857567.9915.27.camel@geddy.wooz.org>

On Fri, 2005-07-08 at 16:24, Reinhold Birkenfeld wrote:

> I compiled a list of some possible new context managers that could be
> added to the stdlib.

I agree with Brett and Phillip that a few well-chosen context managers
would make sense in the stdlib both for convenience and for example
purposes.  Keep the list short and sweet.  Also, I'd like to see some
higher-level cm's in the mix, perhaps implementing concepts like Java's
synchronized (perhaps even being named 'with synchronization').

Thinking about the types of code I write over and over again, I think I
disagree (slightly) with James about the global state thing.  While I
agree that 'with redirected_stdio' isn't too useful in the face of
print>>, I very often have to write try/finally protections around
temporary settings of the cwd, the umask, and other global process
values.  I'd love to see cm's for those constructs in the stdlib.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050708/841cd6d3/attachment.pgp

From reinhold-birkenfeld-nospam at wolke7.net  Fri Jul  8 23:26:25 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Fri, 08 Jul 2005 23:26:25 +0200
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <5.1.1.6.0.20050708165243.02689838@mail.telecommunity.com>
References: <damndu$3fk$1@sea.gmane.org>
	<5.1.1.6.0.20050708165243.02689838@mail.telecommunity.com>
Message-ID: <damr21$539$1@sea.gmane.org>

Phillip J. Eby wrote:
> At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>>        with sys.trace
> 
> Note that it's currently not possible to inspect the trace/profile hooks 
> from Python code, only from C, so that might be, um, interesting to implement.

That was beyond my short view... if it can't be implemented, it won't.

>>* pprint: with pprint.printer (used for print)
> 
> Interesting; I'm not sure if I like it.
> 
>>* os: with os.current_directory
> 
> What does this do?  Oh, I get it.  The name's not very obvious.  I would've 
> expected a more imperative name, something like 'with os.setcwd()' or 'with 
> os.pushdir()'.

I didn't think about the names too long. ;)

>>       with os.modified_env
>>       with os.umask/uid/gid etc.
> 
> Yeah, again I would expect more verbish names, but these are at least 
> easier to grasp than current_directory was.

Names can be found, of course.

>>* curses: with curses.wrapper
>>            with logging.Logger
>>* tty: with tty.raw
>>        with tty.cbreak
>>* cgitb: with cgitb.enabled
> 
> What do these do?

curses: curses.wrapper currently is a function which restores sane terminal
settings after the curses program bails out. It could be a context manager too.
Similar is tty.raw and tty.cbreak. These switch terminal modes, and in case
of an uncaught exception the terminal will stay in this state. Context managers
would restore the "sane" mode on exit.

logging.Logger: hm, I didn't think about that properly.
cgitb: enables or disables the full traceback view (Ok, it wouldn't be so useful).

Reinhold


-- 
Mail address is perfectly valid!


From python at rcn.com  Fri Jul  8 23:26:19 2005
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 8 Jul 2005 17:26:19 -0400
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <bbaeab100507081346e0676dd@mail.gmail.com>
Message-ID: <001601c58403$af8aba80$b432c797@oemcomputer>

> > I compiled a list of some possible new context managers that could
be
> > added to the stdlib. Introducing a new feature should IMO also show
> > usage of it in the distribution itself. That wasn't done with
> > decorators (a decorators module is compiled at the moment, if I'm
> right),
> > but with context managers, there's certainly room to add some. Of
> course,
> > my list is excessive, it's only some ideas I got by flying over the
> stdlib
> > docs.

The PEP contains plenty of examples.  If you're really feeling the need,
add something to the demo directory.

For the most part, the applications need to work themselves out over
time through wikis, individual patch submissions, ASPN recipes,
third-party apps, etc.  

The natural evolution of best practices tends to get thwarted by
prematurely using the standard library to cast a particular solution in
stone.

This doesn't preclude individual patches such as a context manager for
decimal.Context objects.  Each proposal should be considered on its own
merits rather than as a part of an overall effort to ram a bunch of
these into the standard library.    Over time, plenty of these will
sprout-up.



Raymond

From mcherm at mcherm.com  Fri Jul  8 23:39:22 2005
From: mcherm at mcherm.com (Michael Chermside)
Date: Fri, 08 Jul 2005 14:39:22 -0700
Subject: [Python-Dev] Possible context managers in stdlib
Message-ID: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>

James Y Knight writes:
> It is a really bad idea to codify the practice of modifying non-
> threadlocal global state like sys.std[in|out|err] and current
> directory with a context manager.

Barry Warsaw responds:
> Thinking about the types of code I write over and over again, I think I
> disagree (slightly) with James about the global state thing.  While I
> agree that 'with redirected_stdio' isn't too useful in the face of
> print>>, I very often have to write try/finally protections around
> temporary settings of the cwd, the umask, and other global process
> values.  I'd love to see cm's for those constructs in the stdlib.

I agree with Barry. Not only should they be in the stdlib, but they
should have very clear warnings in their docstrings and other documentation
that state that they are ONLY safe to use in single-threaded programs.

This achieves two things: it makes them available to those who need
them (not everyone uses threads!), and it rather forcefully makes the
point that it's NOT usually a good idea to modify global state info in
a context manager because doing so is not generally threadsafe.

-- Michael Chermside


From reinhold-birkenfeld-nospam at wolke7.net  Fri Jul  8 23:40:40 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Fri, 08 Jul 2005 23:40:40 +0200
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <001601c58403$af8aba80$b432c797@oemcomputer>
References: <bbaeab100507081346e0676dd@mail.gmail.com>
	<001601c58403$af8aba80$b432c797@oemcomputer>
Message-ID: <damrso$d2f$1@sea.gmane.org>

Raymond Hettinger wrote:
>> > I compiled a list of some possible new context managers that could
> be
>> > added to the stdlib. Introducing a new feature should IMO also show
>> > usage of it in the distribution itself. That wasn't done with
>> > decorators (a decorators module is compiled at the moment, if I'm
>> right),
>> > but with context managers, there's certainly room to add some. Of
>> course,
>> > my list is excessive, it's only some ideas I got by flying over the
>> stdlib
>> > docs.
> 
> The PEP contains plenty of examples.  If you're really feeling the need,
> add something to the demo directory.
> 
> For the most part, the applications need to work themselves out over
> time through wikis, individual patch submissions, ASPN recipes,
> third-party apps, etc.  
> 
> The natural evolution of best practices tends to get thwarted by
> prematurely using the standard library to cast a particular solution in
> stone.
> 
> This doesn't preclude individual patches such as a context manager for
> decimal.Context objects.  Each proposal should be considered on its own
> merits rather than as a part of an overall effort to ram a bunch of
> these into the standard library.    Over time, plenty of these will
> sprout-up.

As with decorators? Sure, plenty have sprouted up, but delivering them one
release after the feature itself (if the decorators module makes it into 2.5)
seems a little bit like lagging behind -- especially when good and useful
examples exist.

Of course, not all of these in my list are good ideas to implement.

Reinhold

-- 
Mail address is perfectly valid!


From mal at egenix.com  Fri Jul  8 23:46:22 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 08 Jul 2005 23:46:22 +0200
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42CBBC92.4040804@gmail.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	<42C75006.6090902@ronadam.com>	<42C7E146.4090403@gmail.com>	<42C91A07.9030402@gmail.com>
	<42CBBC92.4040804@gmail.com>
Message-ID: <42CEF42E.9040204@egenix.com>

Nick Coghlan wrote:
> OK, here's some draft documentation using Phillip's context 
> terminology. I think it works very well.
> 
> """
> With Statements and Context Management
> 
> A frequent need in programming is to ensure a particular action is
> taken after a specific section of code has been executed (such as 
> closing a file or releasing a lock). The tool to achieve this in 
> Python is to use the 'with' statement along with the appropriate 
> context manager. Context managers ensure a particular action is taken 
> to establish the context before the contained suite is entered, and a 
> second action to clean up the context when the suite is exited.
> 
> The precise behaviour of the 'with' statement is governed by the
> supplied context manager - an object which supports the context 
> management protocol. This protocol consists of two methods:

May I suggest that you use a different name than "context" for
this ?!

The term "context" is way to broad for the application scopes
that you have in mind here (like e.g. managing a resource
in a multi-threaded application).

The PEP talks about "blocks", which is a much more precise term
for what "with" is going to implement, so I'd suggest to call
these thingies "block managers".

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 08 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From martin at v.loewis.de  Fri Jul  8 23:47:24 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 08 Jul 2005 23:47:24 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <upsttn8yk.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>	<42CDA8F9.7080103@v.loewis.de>
	<ufyuqp2fm.fsf@boost-consulting.com>	<42CE0E10.6080509@v.loewis.de>
	<upsttn8yk.fsf@boost-consulting.com>
Message-ID: <42CEF46C.60509@v.loewis.de>

David Abrahams wrote:
> Unless, of course, I'm missing something.  So if I am missing
> something, what is it?

You are missing something, and I can only repeat myself. Some systems
require main() to be compiled as C++, or else constructors may not work
(and perhaps other things fail as well). The configure option --with-cxx
(documented as "enable C++ support") make Python C++ options work on
such systems. It is automatically enabled if a C++ compiler is found.

There is configure auto-detection for what linker is used when
ccpython.o becomes main().

This is the state of the things as it is. In what way would you like to
see that state changed?

I could personally accept if ccpython and --with-cxx would be dropped
entirely (i.e. deliberately breaking systems which require it); I
just notice the irony of history: ccpython.cc was originally introduced
to better support C++ extension modules - now it might get removed
for the very same reason (to better support C++ extension modules).

Regards,
Martin

From martin at v.loewis.de  Sat Jul  9 00:08:08 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 09 Jul 2005 00:08:08 +0200
Subject: [Python-Dev] GCC version compatibility
In-Reply-To: <u8y0hl45u.fsf@boost-consulting.com>
References: <u8y0jz762.fsf@boost-consulting.com>	<42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com>
Message-ID: <42CEF948.3010908@v.loewis.de>

David Abrahams wrote:
>>When I looked into this problem I saw that configure in fact builds a test
>>executable that included an object file compiled with g++. If the link step
>>with gcc succeeds then LINKCC is set as above, otherwise CXX is
>>used. Obviously, on my system this test was successful so configure decided
>>to link with gcc. However, minimal changes to the source of the test program
>>caused the link step to fail. It was not obvious to me at all why the latter
>>source code should cause a dependency on the C++ runtime if the original
>>code does not. My conclusion was that this test is fragile and should be
>>skipped. 
> 
> 
> Sounds like it.  I have never understood what the test was really
> checking for since the moment it was first described to me, FWIW.

I'll describe it once more: *If* a program is compiled with the C++
compiler, is it *then* possible to still link it with the C compiler?
This is the question this test tries to answer.

>>If Python is built with --with-cxx then it should be linked with CXX
>>as well.
> 
> 
> U betcha.

Wrong. The test was introduced in response to complaints that Python
unnecessarily links with libstdc++ on some Linux systems. On these
Linux systems, it was well possible to build main() with a C++ compiler,
and still link the entire thing with gcc. Since main() doesn't use
any libstdc++ functionality, and since collect2/__main isn't used,
one would indeed expect that linking with CXX is not necessary.

>>(On ELF based Linux/x86, at least.) That leaves me wondering
>>
>> * when is --with-cxx really necessary?
> 
> 
> I think it's plausible that if you set sys.dlopenflags

This has no relationship at all. --with-cxx is much older than
sys.dlopenflags. It is used on systems where main() must be a
C++ program for C++ extension modules to work (e.g. some Linux
systems).

Regards,
Martin

From skip at pobox.com  Sat Jul  9 00:21:12 2005
From: skip at pobox.com (Skip Montanaro)
Date: Fri, 8 Jul 2005 17:21:12 -0500
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>
References: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>
Message-ID: <17102.64600.669006.871379@montanaro.dyndns.org>

Ummm...  What's a "context manager"?

Skip

From martin at v.loewis.de  Sat Jul  9 00:29:05 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 09 Jul 2005 00:29:05 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <upstup7r9.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CD3052.6000704@acm.org>	<uy88ivgg0.fsf@boost-consulting.com>	<17101.16300.736797.378762@montanaro.dyndns.org>	<ud5putpjj.fsf@boost-consulting.com>	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com>
Message-ID: <42CEFE31.1000800@v.loewis.de>

David Abrahams wrote:
>>If there is some library with such objects that happens to get
>>wrapped and dynamically linked into a Python interpreter 
> 
> 
> Whoa there.  How would that ever happen under ordinary circumstances?
> Doesn't Python's makefile control what gets linked to Python?

Not entirely. By extending Modules/Setup (e.g. in the way freeze works),
it is well possible to have additional extension modules linked into the
Python interpreter, extension modules which are not part of the
standard Python distribution.

In fact, before Python supported dynamic loading of extension modules,
this was the *only* way to use non-standard extension modules. You
always had to build your own version of the Python interpreter. I
believe ccpython.cc dates back to these times.

> If there's someone around here who is responsible for this change and
> knows its real rationale, can (s)he please tell me what it is?  If
> not, can we please change things back so Python doesn't get linked to
> the C++ runtime by default?

ccpython.cc and --with-cxx was first published in Python 1.6, and
hasn't changed much since. So for some of you, it has "always"
been there. It was contributed by Geoff Furnish.

What *has* changed now is that the configure test suddenly determines
that you need to link with g++ on Linux if main was compiled with g++.
This was not the case before, but now is (since g++ 3.2 or something).

Regards,
Martin

From ncoghlan at gmail.com  Sat Jul  9 02:43:33 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 09 Jul 2005 10:43:33 +1000
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42CEF42E.9040204@egenix.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	<42C75006.6090902@ronadam.com>	<42C7E146.4090403@gmail.com>	<42C91A07.9030402@gmail.com>	<42CBBC92.4040804@gmail.com>
	<42CEF42E.9040204@egenix.com>
Message-ID: <42CF1DB5.6090602@gmail.com>

M.-A. Lemburg wrote:
> May I suggest that you use a different name than "context" for
> this ?!
> 
> The term "context" is way to broad for the application scopes
> that you have in mind here (like e.g. managing a resource
> in a multi-threaded application).

It's actually the broadness of the term 'context' which is appealing - the 
examples in the draft documentation on SF are:

   - resource management (synchronisation locks, generic 'closing')
   - HTML tag matching
   - Decimal arithmetic context

Any earlier version used 'suite managers' (partly to avoid confusing the hell 
out of anyone ever exposed to Ruby's concept of blocks), but the 'context 
management' term seems to more clearly describe what the protocol is for.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From ncoghlan at gmail.com  Sat Jul  9 03:03:09 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 09 Jul 2005 11:03:09 +1000
Subject: [Python-Dev] 'With' context documentation draft (was
 Re:	Terminology for PEP 343
In-Reply-To: <damgjs$fbt$1@sea.gmane.org>
References: <42C91A07.9030402@gmail.com><000701c57e8f$86c35ae0$aa36c797@oemcomputer><42C75006.6090902@ronadam.com>	<42C7E146.4090403@gmail.com><42C91A07.9030402@gmail.com><5.1.1.6.0.20050707141420.02674e58@mail.telecommunity.com>	<42CE8BEF.9050508@gmail.com>
	<damgjs$fbt$1@sea.gmane.org>
Message-ID: <42CF224D.5020709@gmail.com>

Terry Reedy wrote:
> Would this also work as a decorated generator?
> (If I have understood correctly, something like..)
> 
> @contextmanager
> def tag(name)
>        print "<%s>" % name
>        yield None
>        print "</%s>" % name
> 
> If so, I suggest putting in both versions to make the correspondence clear.

Hmm, good idea. I think I'll do that with 'closing' as well, since the 
resource management section could use a better example.

> To whoever invented this example: thanks.  It rang a bell with me so I 
> could see this as a generally usefully feature rather than a specialized 
> (though for some, important) 'close resource' feature.
> 
> The particularly neat thing is that it converts the indent-dedent method of 
> showing structure to the alternative matched-fences method.   This is 
> certainly not limited to HTML generation.

By using closing(), decimal.getcontext(), and tag() as examples, it should be 
possible to show the versatility of the construct without making the 
documentation too confusing.

Cheers,
Nick.

[1] http://www.python.org/sf/1234057

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From ncoghlan at gmail.com  Sat Jul  9 03:04:53 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 09 Jul 2005 11:04:53 +1000
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>
References: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>
Message-ID: <42CF22B5.4050600@gmail.com>

Michael Chermside wrote:
> I agree with Barry. Not only should they be in the stdlib, but they
> should have very clear warnings in their docstrings and other documentation
> that state that they are ONLY safe to use in single-threaded programs.
> 
> This achieves two things: it makes them available to those who need
> them (not everyone uses threads!), and it rather forcefully makes the
> point that it's NOT usually a good idea to modify global state info in
> a context manager because doing so is not generally threadsafe.

Wouldn't they be able to actually emit a warning at run-time if they're used 
in a multi-threaded program? That would be even better motivation for 
including them, IMO.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From dave at boost-consulting.com  Sat Jul  9 03:20:26 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Jul 2005 21:20:26 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42CEF46C.60509@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6wi?=
	=?iso-8859-1?Q?s's?= message of "Fri, 08 Jul 2005 23:47:24 +0200")
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CDA8F9.7080103@v.loewis.de> <ufyuqp2fm.fsf@boost-consulting.com>
	<42CE0E10.6080509@v.loewis.de> <upsttn8yk.fsf@boost-consulting.com>
	<42CEF46C.60509@v.loewis.de>
Message-ID: <ubr5chj1h.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>> Unless, of course, I'm missing something.  So if I am missing
>> something, what is it?
>
> You are missing something, and I can only repeat myself. Some systems
> require main() to be compiled as C++, or else constructors may not work
> (and perhaps other things fail as well). 

Yes, and that becomes important in programs that have constructors.
I.e., C++ programs.  The Python executable is not such a program,
except for one C++ file: ccpython.cc.  There is no reason that file
couldn't be rewritten as a pure 'C' file and any need for Python to be
linked with G++ would disappear.

> The configure option --with-cxx (documented as "enable C++ support")
> make Python C++ options 

What are "Python C++ options?"

> work on such systems. It is automatically enabled if a C++ compiler
> is found.
>
> There is configure auto-detection for what linker is used when
> ccpython.o becomes main().
>
> This is the state of the things as it is. In what way would you like to
> see that state changed?

I would like the Python executable never to be linked (or compiled
either) by g++ unless that is explicitly requested by the person
invoking configure or make.

> I could personally accept if ccpython and --with-cxx would be dropped
> entirely (i.e. deliberately breaking systems which require it); 

I don't believe any systems require it.  I realize you have said
otherwise, but after years of working with Boost.Python I'm very
familiar with the issues of dynamic linking and C/C++ interoperability
on a wide variety of platforms, and I'm not convinced by your
assertion.  If such a system exists, it should be easy for someone to
point me at it, and show that something breaks.

> I just notice the irony of history: ccpython.cc was originally
> introduced to better support C++ extension modules - now it might
> get removed for the very same reason (to better support C++
> extension modules).

Indeed.  I was amazed to read in the log that it was introduced in
1995 for that reason.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From dave at boost-consulting.com  Sat Jul  9 03:38:44 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Jul 2005 21:38:44 -0400
Subject: [Python-Dev] GCC version compatibility
In-Reply-To: <42CEF948.3010908@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sat, 09 Jul 2005 00:08:08 +0200")
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
Message-ID: <u3bqohi6z.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>>>When I looked into this problem I saw that configure in fact builds a test
>>>executable that included an object file compiled with g++. If the link step
>>>with gcc succeeds then LINKCC is set as above, otherwise CXX is
>>>used. Obviously, on my system this test was successful so configure decided
>>>to link with gcc. However, minimal changes to the source of the test program
>>>caused the link step to fail. It was not obvious to me at all why the latter
>>>source code should cause a dependency on the C++ runtime if the original
>>>code does not. My conclusion was that this test is fragile and should be
>>>skipped. 
>> 
>> 
>> Sounds like it.  I have never understood what the test was really
>> checking for since the moment it was first described to me, FWIW.
>
> I'll describe it once more: *If* a program is compiled with the C++
> compiler, is it *then* possible to still link it with the C compiler?
> This is the question this test tries to answer.

Okay, I understand that.  What I have never understood is why that
should be an appropriate thing to test for the Python executable.
There's no reason to compile any of Python with a C++ compiler.

>>>If Python is built with --with-cxx then it should be linked with CXX
>>>as well.
>> 
>> U betcha.
>
> Wrong. The test was introduced in response to complaints that Python
> unnecessarily links with libstdc++ on some Linux systems. 

Apparently it still does.

> On these Linux systems, it was well possible to build main() with a
> C++ compiler

Nobody would need to build Python's main() with a C++ compiler, if
you'd just comment out the 'extern "C"'.

> and still link the entire thing with gcc. Since main() doesn't use
> any libstdc++ functionality, and since collect2/__main isn't used,
> one would indeed expect that linking with CXX is not necessary.

It isn't.

>>>(On ELF based Linux/x86, at least.) That leaves me wondering
>>>
>>> * when is --with-cxx really necessary?
>> 
>> 
>> I think it's plausible that if you set sys.dlopenflags
>
> This has no relationship at all. --with-cxx is much older than
> sys.dlopenflags. It is used on systems where main() must be a
> C++ program for C++ extension modules to work (e.g. some Linux
> systems).

I have tested Boost.Python and C++ extension modules on a wide variety
of Linux systems, and have seen this phenomenon.  Everyone who is
testing it on Linux is finding that if they build Python
--without-cxx, everything works.  And, yes, the mechanisms at the very
*core* of Boost.Python rely on static initializers being run properly,
so if there were anything wrong with that mechanism the tests would be
breaking left and right.

I think either the ELF Linux loader changed substantially since 1995,
or whoever introduced this test was just confused.

C++ extension modules get their static initializers run when they are
loaded by dlopen (or, strictly speaking, sometime between then and the
time their code begins to execute) which happens long after main or
__main are invoked.  The executable doesn't know about these extension
modules until they are loaded, and when it loads them it can't get its
hooks into anything other than the initmodulename entry point.  The
executable does not trigger the static initializers; the dynamic
loader does.  Therefore, it doesn't matter whether the executable is
linked with the C++ runtime.  An appropriate C++ runtime is linked to
the extension module and that is what gets invoked when the module is
loaded.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From dave at boost-consulting.com  Sat Jul  9 03:46:42 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Jul 2005 21:46:42 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42CEFE31.1000800@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sat, 09 Jul 2005 00:29:05 +0200")
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
Message-ID: <uy88gg399.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>>>If there is some library with such objects that happens to get
>>>wrapped and dynamically linked into a Python interpreter 
>> 
>> 
>> Whoa there.  How would that ever happen under ordinary circumstances?
>> Doesn't Python's makefile control what gets linked to Python?
>
> Not entirely. By extending Modules/Setup 

You mean 
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/Setup.dist?view=markup
?

> e.g. in the way freeze works), it is well possible to have
> additional extension modules linked into the Python interpreter,
> extension modules which are not part of the standard Python
> distribution.
>
> In fact, before Python supported dynamic loading of extension
> modules, this was the *only* way to use non-standard extension
> modules. You always had to build your own version of the Python
> interpreter. I believe ccpython.cc dates back to these times.

That explains a lot.  

I contend that either:

   a.  Anyone making that sort of extension with a C++ module should
   explicitly request --with-cxx, or

   b.  The python build system should automatically detect that
   --with-cxx is needed based on the presence of C++ extension
   modules.

Frankly I think b. would require an impractical amount of work and,
speaking as an author of C++ extension modules, I don't think a. is
much of a burden to impose.

>> If there's someone around here who is responsible for this change and
>> knows its real rationale, can (s)he please tell me what it is?  If
>> not, can we please change things back so Python doesn't get linked to
>> the C++ runtime by default?
>
> ccpython.cc and --with-cxx was first published in Python 1.6, and
> hasn't changed much since. So for some of you, it has "always" been
> there. It was contributed by Geoff Furnish.
>
> What *has* changed now is that the configure test suddenly
> determines that you need to link with g++ on Linux if main was
> compiled with g++.  This was not the case before, but now is (since
> g++ 3.2 or something).

I see.  Well, everything has become clear, thank you.  My proposed
remedy hasn't changed, though.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From tjreedy at udel.edu  Sat Jul  9 05:25:46 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 8 Jul 2005 23:25:46 -0400
Subject: [Python-Dev] checklist for filing a bug
References: <bbaeab10050707211922059724@mail.gmail.com>
	<000f01c583ff$2a15d460$b432c797@oemcomputer>
Message-ID: <dang3r$j1t$1@sea.gmane.org>


"Raymond Hettinger" <python at rcn.com> wrote in message 
news:000f01c583ff$2a15d460$b432c797 at oemcomputer...
>> In order to lower the barrier for reporting bugs, writing patches, and
>> handling CVS commits, I am writing up checklists for each and I will
>> put them up on python.org.
>
> -0 on the checklists.

I am more enthusiastic about the idea of improving python.com's guidelines 
in this area, with some of Raymond's comments, and mine below, taken into 
consideration.  To start with, I think the Developers page should have Bug 
Submission Guidelines to go with the Patch Submission Guidelines.

Searching the site for 'bug reports' gives PEP 3 *Handling* (not 
submitting) Bug Reports as first hit.  It seems to have last been revised 
4-5 years ago.  Is there anything more recent I should be aware of?  PEP 3 
references Appendix B. Reporting Bugs of the current docs.  I believe this 
page could stand revision to be more list a checklist.

The search engine does *not* return this page (current App. B) among the 
first 10 of 19,000 (really?) reported hits.  I wish we could 'buy' words 
(for free) for searches on our own site or otherwise learn how to influence 
the search results.  The top 10 do include the appendix for earlier 
versions.  But this will won't help get people to the most recent version.

The search engine also reports Known Bugs lists such as 
http://www.python.org/2.4/bugs.html.
At the bottom is a very short blurb of how to report bugs, which does 
reference Appendix B (nor, of course, to your yet to be posted page).  The 
same applies to http://www.python.org/dev/tools.html.  I would really like 
to see one page, occasionally revised, that is referenced wherever the 
subject is discussed on the site.

Some specifics based on my experience reviewing bugs, mostly as 'triage 
nurse'.

I would like to see more emphasis that the Python SF bug list is for bugs 
in the PSF distribution, including documentation and std libs, which we can 
fix, and not for other stuff, including feature requests (see RFE tracker), 
non-bug change proposals (see PEPs), and bugs in 3rd party libraries and 
compilers (see their bug lists).

I would like it stated that a bug is generally a discrepancy between 
promise -- the documentaion-- and performance -- the implementation. 
(Non-documentation is another area.)  This means that 'reporting a bug' 
often means finding and reporting the section of the documentation -- the 
language or library reference -- that conflicts with the reported behavior. 
Many bugs reported today are not as obviously bugs as
>>> 2+2
5

I agree with Raymond that unittests are a nice optional extra but too much 
to expect.  You could mention that providing good, simple code 
demonstrating the bug, perhaps with multiple data inputs, makes it easier 
for the bug fixer to write a test so that the bug will be caught if 
reintroduced.

In summary, I think a good guideline page could improve reports and make 
first-reviews easier.

Terry J. Reedy




From nyamatongwe at gmail.com  Sat Jul  9 05:50:52 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sat, 9 Jul 2005 13:50:52 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <wto1wdzv.fsf@python.net>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
	<ca471dc2050703112845321ad3@mail.gmail.com>
	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<50862ebd05070604117e9c5fb4@mail.gmail.com> <y88j3pqo.fsf@python.net>
	<50862ebd05070805431808b7e5@mail.gmail.com> <wto1wdzv.fsf@python.net>
Message-ID: <50862ebd05070820506a829c45@mail.gmail.com>

Thomas Heller:

> But adding u'\u5b66\u6821\u30c7\u30fc' to sys.path won't allow to import
> this file as module.  Internally Python\import.c converts everything to
> strings.  I started to refactor import.c to work with PyStringObjects
> instead of char buffers as a first step - PyUnicodeObjects could have
> been added later, but I gave up because there seems absolute zero
> interest in it.

   Well, most people when confronted with this will rename the
directory to something simple like "ulib" and continue.

> I can't judge on this - but it's easy to experiment with it, even in
> current Python releases since sys.argvu, os.environu can also be
> provided by extension modules.

   It is the effect of this on the non-unicode-savvy that is
important: if os.environu goes into prereleases of 2.5 then the only
people that will use it are likely to be those who already try to keep
their code unicode compliant. There is only likely to be (negative)
feedback if existing features are made unicode-only or use unicode for
non-ASCII.

> But thanks that you care about this stuff - I'm a little bit worried
> because all the other folks seem to think everything's ok (?).

   Unicode is becoming more of an issue: many Linux distributions now
install by default with a UTF8 locale and other tools are starting to
use this: GCC 4 now delivers error messages using Unicode quote
characters like 'these' rather than `these'. There are 131 threads
found by Google Groups for (UnicodeEncodeError OR UnicodeDecodeError)
and 21 of these were in this June. A large proportion of the threads
are in language-specific groups so are not as visible to core
developers.

   Neil

From greg.ewing at canterbury.ac.nz  Sat Jul  9 07:20:12 2005
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 09 Jul 2005 17:20:12 +1200
Subject: [Python-Dev] Chaining try statements: eltry?
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
Message-ID: <42CF5E8C.6070103@canterbury.ac.nz>

Guido van Rossum wrote:

> I sometimes think it was
> a mistake to introduce elif just to save typing "else if".
> 
> The problem with the elwhile/elfor/eltry idea 
 > is that you're just as likely to need e.g.
> a "try" in the else clause of a while-loop as another while,

Here's an idea for Python 3000 which addresses both of
these: Split 'elif' back up into 'else if', but also
generalise it so that any 'else' can be followed by any
suite-introducing statement. Then you get all possible
combinations for free.

Greg


From ncoghlan at gmail.com  Sat Jul  9 09:28:53 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 09 Jul 2005 17:28:53 +1000
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <42CF5E8C.6070103@canterbury.ac.nz>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>	<ca471dc2050706120231ecb092@mail.gmail.com>	<20050707103833.327547ed.thomas@thomas-lotze.de>	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<42CF5E8C.6070103@canterbury.ac.nz>
Message-ID: <42CF7CB5.3000300@gmail.com>

Greg Ewing wrote:
> Guido van Rossum wrote:
> 
> 
>>I sometimes think it was
>>a mistake to introduce elif just to save typing "else if".
>>
>>The problem with the elwhile/elfor/eltry idea 
> 
>  > is that you're just as likely to need e.g.
> 
>>a "try" in the else clause of a while-loop as another while,
> 
> 
> Here's an idea for Python 3000 which addresses both of
> these: Split 'elif' back up into 'else if', but also
> generalise it so that any 'else' can be followed by any
> suite-introducing statement. Then you get all possible
> combinations for free.

I don't think that's a good idea. What would the following monstrosity mean?:

   if 0:
       print "Ran the if"
   else for item in (1, 2, 3):
       print item
   else try:
       print "No exception here!"
   except:
       pass
   else:
       print "Who's else is this, anyway?"

The use-case of 'elif' or 'else if' to avoid nested if statements is strong, 
but the use cases for the ability to mix compound statements together is 
significantly weaker.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From ulrich.berning at t-online.de  Sat Jul  9 10:20:35 2005
From: ulrich.berning at t-online.de (Ulrich Berning)
Date: Sat, 09 Jul 2005 10:20:35 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <ubr5chj1h.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>	<42CDA8F9.7080103@v.loewis.de>
	<ufyuqp2fm.fsf@boost-consulting.com>	<42CE0E10.6080509@v.loewis.de>
	<upsttn8yk.fsf@boost-consulting.com>	<42CEF46C.60509@v.loewis.de>
	<ubr5chj1h.fsf@boost-consulting.com>
Message-ID: <42CF88D3.9090005@t-online.de>

David Abrahams schrieb:

>"Martin v. L?wis" <martin at v.loewis.de> writes:
>
>  
>
>>David Abrahams wrote:
>>    
>>
>>>Unless, of course, I'm missing something.  So if I am missing
>>>something, what is it?
>>>      
>>>
>>You are missing something, and I can only repeat myself. Some systems
>>require main() to be compiled as C++, or else constructors may not work
>>(and perhaps other things fail as well). 
>>    
>>
>
>Yes, and that becomes important in programs that have constructors.
>I.e., C++ programs.  The Python executable is not such a program,
>except for one C++ file: ccpython.cc.  There is no reason that file
>couldn't be rewritten as a pure 'C' file and any need for Python to be
>linked with G++ would disappear.
>
>  
>
>>The configure option --with-cxx (documented as "enable C++ support")
>>make Python C++ options 
>>    
>>
>
>What are "Python C++ options?"
>
>  
>
>>work on such systems. It is automatically enabled if a C++ compiler
>>is found.
>>
>>There is configure auto-detection for what linker is used when
>>ccpython.o becomes main().
>>
>>This is the state of the things as it is. In what way would you like to
>>see that state changed?
>>    
>>
>
>I would like the Python executable never to be linked (or compiled
>either) by g++ unless that is explicitly requested by the person
>invoking configure or make.
>
>  
>
>>I could personally accept if ccpython and --with-cxx would be dropped
>>entirely (i.e. deliberately breaking systems which require it); 
>>    
>>
>
>I don't believe any systems require it.  I realize you have said
>otherwise, but after years of working with Boost.Python I'm very
>familiar with the issues of dynamic linking and C/C++ interoperability
>on a wide variety of platforms, and I'm not convinced by your
>assertion.  If such a system exists, it should be easy for someone to
>point me at it, and show that something breaks.
>
>  
>
If you build C++ extensions on HP-UX with aCC, Python must be compiled 
and linked as a C++ program. This is documented.
It will not work if Python is compiled and linked as a normal C program 
(I have tried it). I haven't tried gcc on this platform, but I guess it 
is the same (compile and link with g++).

Ulli




From rwgk at cci.lbl.gov  Sat Jul  9 11:51:19 2005
From: rwgk at cci.lbl.gov (Ralf W. Grosse-Kunstleve)
Date: Sat, 9 Jul 2005 02:51:19 -0700 (PDT)
Subject: [Python-Dev] __autoinit__
Message-ID: <200507090951.j699pJDX439105@boa.lbl.gov>

For those who didn't like my proposal a week ago, please have another
look:

http://mail.python.org/pipermail/python-list/2005-July/289446.html

Please reply only to python-list.

Cheers,
        Ralf

From mal at egenix.com  Sat Jul  9 13:06:37 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 09 Jul 2005 13:06:37 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE
	for	review)
In-Reply-To: <50862ebd05070820506a829c45@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>	<ca471dc20506272343cbe7614@mail.gmail.com>	<50862ebd05063016466f3e6abd@mail.gmail.com>	<ca471dc2050703112845321ad3@mail.gmail.com>	<50862ebd05070317183d971bef@mail.gmail.com>	<ca471dc205070400441ab49ffb@mail.gmail.com>	<50862ebd05070604117e9c5fb4@mail.gmail.com>
	<y88j3pqo.fsf@python.net>	<50862ebd05070805431808b7e5@mail.gmail.com>
	<wto1wdzv.fsf@python.net>
	<50862ebd05070820506a829c45@mail.gmail.com>
Message-ID: <42CFAFBD.2010202@egenix.com>

Neil Hodgson wrote:
> Thomas Heller:
> 
> 
>>But adding u'\u5b66\u6821\u30c7\u30fc' to sys.path won't allow to import
>>this file as module.  Internally Python\import.c converts everything to
>>strings.  I started to refactor import.c to work with PyStringObjects
>>instead of char buffers as a first step - PyUnicodeObjects could have
>>been added later, but I gave up because there seems absolute zero
>>interest in it.
>
>    Well, most people when confronted with this will rename the
> directory to something simple like "ulib" and continue.

I don't really buy this "trick": what if you happen to have
a home directory with Unicode characters in it ?

>>I can't judge on this - but it's easy to experiment with it, even in
>>current Python releases since sys.argvu, os.environu can also be
>>provided by extension modules.
> 
> 
>    It is the effect of this on the non-unicode-savvy that is
> important: if os.environu goes into prereleases of 2.5 then the only
> people that will use it are likely to be those who already try to keep
> their code unicode compliant. There is only likely to be (negative)
> feedback if existing features are made unicode-only or use unicode for
> non-ASCII.

I don't like the idea of creating a parallel universe for
Unicode - OSes are starting to integrate Unicode filenames
rather quickly (UTF-8 on Unix, UTF-16-LE on Windows), so
it's much better to follow them and start accepting Unicode in
sys.path.

Wouldn't it be easy to have the import logic convert Unicode
entries in sys.path to whatever the OS uses internally (UTF-8
or UTF-16-LE) and then keep the char buffers in place ?

>>But thanks that you care about this stuff - I'm a little bit worried
>>because all the other folks seem to think everything's ok (?).
> 
>    Unicode is becoming more of an issue: many Linux distributions now
> install by default with a UTF8 locale and other tools are starting to
> use this: GCC 4 now delivers error messages using Unicode quote
> characters like 'these' rather than `these'. There are 131 threads
> found by Google Groups for (UnicodeEncodeError OR UnicodeDecodeError)
> and 21 of these were in this June. A large proportion of the threads
> are in language-specific groups so are not as visible to core
> developers.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 09 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From aahz at pythoncraft.com  Sat Jul  9 13:57:48 2005
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 9 Jul 2005 04:57:48 -0700
Subject: [Python-Dev] __autoinit__
In-Reply-To: <200507090951.j699pJDX439105@boa.lbl.gov>
References: <200507090951.j699pJDX439105@boa.lbl.gov>
Message-ID: <20050709115748.GA12397@panix.com>

On Sat, Jul 09, 2005, Ralf W. Grosse-Kunstleve wrote:
>
> For those who didn't like my proposal a week ago, please have another
> look:
> 
> http://mail.python.org/pipermail/python-list/2005-July/289446.html
> 
> Please reply only to python-list.

Looks like you mis-sent this to python-dev; you probably want to resend.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From dave at boost-consulting.com  Sat Jul  9 14:40:27 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 09 Jul 2005 08:40:27 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42CF88D3.9090005@t-online.de> (Ulrich Berning's message of "Sat, 
	09 Jul 2005 10:20:35 +0200")
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CDA8F9.7080103@v.loewis.de> <ufyuqp2fm.fsf@boost-consulting.com>
	<42CE0E10.6080509@v.loewis.de> <upsttn8yk.fsf@boost-consulting.com>
	<42CEF46C.60509@v.loewis.de> <ubr5chj1h.fsf@boost-consulting.com>
	<42CF88D3.9090005@t-online.de>
Message-ID: <ur7e8f8zo.fsf@boost-consulting.com>

Ulrich Berning <ulrich.berning at t-online.de> writes:

> If you build C++ extensions on HP-UX with aCC, Python must be compiled 
> and linked as a C++ program. This is documented.

You mean dynamically loaded C++ extensions, or the kind that are
linked into the Python executable?

I'm willing to believe almost anything about HP-UX.  Until recently,
aCC was so broken as a C++ compiler that there was little point in
trying to get Boost.Python to work on it, and I don't have much data
for that system.

> It will not work if Python is compiled and linked as a normal C
> program (I have tried it).

Even if you take out the use of C++ constructs in ccpython.cc?  I just
need to check all the obvious angles.

> I haven't tried gcc on this platform, but I guess it is the same
> (compile and link with g++).

Okay, but -- at the very least -- we don't need this behavior on
ELF/Linux.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From nyamatongwe at gmail.com  Sat Jul  9 15:04:38 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sat, 9 Jul 2005 23:04:38 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <42CFAFBD.2010202@egenix.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<ca471dc2050703112845321ad3@mail.gmail.com>
	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<50862ebd05070604117e9c5fb4@mail.gmail.com> <y88j3pqo.fsf@python.net>
	<50862ebd05070805431808b7e5@mail.gmail.com> <wto1wdzv.fsf@python.net>
	<50862ebd05070820506a829c45@mail.gmail.com>
	<42CFAFBD.2010202@egenix.com>
Message-ID: <50862ebd0507090604290df5f6@mail.gmail.com>

M.-A. Lemburg:

> I don't really buy this "trick": what if you happen to have
> a home directory with Unicode characters in it ?

   Most people choose account names and thus home directory names that
are compatible with their preferred locale settings: German users are
unlikely to choose an account name that uses Japanese characters.
Unicode is only necessary for file names that are outside your default
locale. An administration utility may need to visit multiple user's
home directories and so is more likely to encounter files with names
that can not be represented in its default locale.

   I think it would be better if sys.path could include unicode
entries but expect the code will rarely be exercised.

   Neil

From thomas at thomas-lotze.de  Sat Jul  9 15:54:17 2005
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Sat, 09 Jul 2005 15:54:17 +0200
Subject: [Python-Dev] Chaining try statements: eltry?
References: <20050706200745.22493ade.thomas@thomas-lotze.de>	<ca471dc2050706120231ecb092@mail.gmail.com>	<20050707103833.327547ed.thomas@thomas-lotze.de>	<ca471dc2050707063938b19fb2@mail.gmail.com>	<42CF5E8C.6070103@canterbury.ac.nz>
	<42CF7CB5.3000300@gmail.com>
Message-ID: <pan.2005.07.09.10.31.34.883296@ID-174572.user.uni-berlin.de>

Nick Coghlan wrote:

> I don't think that's a good idea. What would the following monstrosity
> mean?:
> 
>    if 0:
>        print "Ran the if"
>    else for item in (1, 2, 3):
>        print item
>    else try:
>        print "No exception here!"
>    except:
>        pass
>    else:
>        print "Who's else is this, anyway?"

It is unambiguous. But:

> The use-case of 'elif' or 'else if' to avoid nested if statements is
> strong, but the use cases for the ability to mix compound statements
> together is significantly weaker.

This is not even about use cases anymore, it's about usability.
Indentation (by indicating nesting) serves well to recognize at first
sight what belongs together, and what doesn't. Mixing compound statements
breaks this, as it requires the reader to think about it twice, if that's
even enough.

-- 
Thomas



From rwgk at yahoo.com  Fri Jul  8 23:40:00 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 8 Jul 2005 14:40:00 -0700 (PDT)
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
In-Reply-To: <u8y0hl45u.fsf@boost-consulting.com>
Message-ID: <20050708214000.29643.qmail@web31514.mail.mud.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Yes, all the tests are passing that way.
> 
> > (On ELF based Linux/x86, at least.) That leaves me wondering
> >
> >  * when is --with-cxx really necessary?
> 
> I think it's plausible that if you set sys.dlopenflags to share
> symbols it *might* end up being necessary, but IIRC Ralf does use
> sys.dlopenflags with a standard build of Python (no
> --with-cxx)... right, Ralf?

Yes, I am using sys.setdlopenflags like this:

  if (sys.platform == "linux2"):
    sys.setdlopenflags(0x100|0x2)

/usr/include/bits/dlfcn.h:#define RTLD_GLOBAL      0x00100
/usr/include/bits/dlfcn.h:#define RTLD_NOW 0x00002

Note that the default Python 2.4.1 installation links python with g++. I've
never had any problems with this configuration under any Linux version, at
least: Redhat 7.3, 8.0, 9.0, WS3, SuSE 9.2, Fedora Core 3, and some other
versions I am not sure about.

Specifically for this posting I've installed Python 2.4.1 --without-cxx. All of
our 50 Boost.Python extensions still work without a problem.

Cheers,
        Ralf



		
____________________________________________________
Sell on Yahoo! Auctions ? no fees. Bid on great items.  
http://auctions.yahoo.com/

From cludwig at cdc.informatik.tu-darmstadt.de  Sat Jul  9 12:20:11 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sat, 9 Jul 2005 12:20:11 +0200
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
In-Reply-To: <42CEF948.3010908@v.loewis.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
Message-ID: <20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>

On Sat, Jul 09, 2005 at 12:08:08AM +0200, "Martin v. L?wis" wrote:
> David Abrahams wrote:
> >>When I looked into this problem I saw that configure in fact builds a test
> >>executable that included an object file compiled with g++. If the link step
> >>with gcc succeeds then LINKCC is set as above, otherwise CXX is
> >>used. Obviously, on my system this test was successful so configure decided
> >>to link with gcc. However, minimal changes to the source of the test program
> >>caused the link step to fail. It was not obvious to me at all why the latter
> >>source code should cause a dependency on the C++ runtime if the original
> >>code does not. My conclusion was that this test is fragile and should be
> >>skipped. 
> > 
> > 
> > Sounds like it.  I have never understood what the test was really
> > checking for since the moment it was first described to me, FWIW.
> 
> I'll describe it once more: *If* a program is compiled with the C++
> compiler, is it *then* possible to still link it with the C compiler?
> This is the question this test tries to answer.

The keyword here is "tries" - my bug report #1189330 exihibts that the test
fails to do its job. And looking at the test that's certainly no surprise:

configure writes the following conftest.cc on the disk (whitespaces added for
better readability):

  cludwig at lap200:~/tmp/python-config> cat conftest.cc
  void foo();

  int main() {
    foo();
  }

  void foo() {
  } 

This TU is compiled with the C++ compiler and then linked with the C compiler:

  cludwig at lap200:~/tmp/python-config> g++ -o conftest.o -c conftest.cc
  cludwig at lap200:~/tmp/python-config> gcc -o conftest conftest.o

Note that there is *no* reference to any symbol in another TU. The compiler
can detect that foo() won't throw any exceptions, that there is no need for RTTI
and whatever else the C++ runtime provides. Consequently, the object file
produced by g++ does not contain any reference to symbols in libstdc++.

However, python.c does reference a function from other TUs, in particular
extern "C" int Py_Main(int, char**). The following test shows that in this
situation you must link with g++:

  cludwig at lap200:~/tmp/python-config> cat conftest_a.cc
  extern "C" void foo();

  int main() {
    foo();
  }
  cludwig at lap200:~/tmp/python-config> cat conftest_b.c
  void foo() {
  }
  cludwig at lap200:~/tmp/python-config> g++ -o conftest_a.o -c conftest_a.cc
  cludwig at lap200:~/tmp/python-config> gcc -o conftest_b.o -c conftest_b.c
  cludwig at lap200:~/tmp/python-config> gcc -o conftest conftest_a.o conftest_b.o
  conftest_a.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
  collect2: ld gab 1 als Ende-Status zur?ck

(I ran this test with g++ 3.3.1, 3.4.2, and 4.0.0 with identical results.) The
reason is, I guess, that even though foo() is delared to have "C" linkage, it
still can throw a C++ exception. 

> >>If Python is built with --with-cxx then it should be linked with CXX
> >>as well.
> > 
> > 
> > U betcha.
> 
> Wrong. The test was introduced in response to complaints that Python
> unnecessarily links with libstdc++ on some Linux systems. On these
> Linux systems, it was well possible to build main() with a C++ compiler,
> and still link the entire thing with gcc. Since main() doesn't use
> any libstdc++ functionality, and since collect2/__main isn't used,
> one would indeed expect that linking with CXX is not necessary.

Of course, if you insist on this "dependency optimization" then you can try to
fix Python's configure.in by using the second test above. But I would still
not trust it to cover all configurations on all platforms supported by
Python. 

> >>(On ELF based Linux/x86, at least.) That leaves me wondering
> >>
> >> * when is --with-cxx really necessary?
> > 
> > 
> > I think it's plausible that if you set sys.dlopenflags
> 
> This has no relationship at all. --with-cxx is much older than
> sys.dlopenflags. It is used on systems where main() must be a
> C++ program for C++ extension modules to work (e.g. some Linux
> systems).

Can you provide a concrete examples of such systems? The explanation of
--with-cxx in the README mentions a.out. Are there other systems?

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html


From T.A.Meyer at massey.ac.nz  Sat Jul  9 13:31:57 2005
From: T.A.Meyer at massey.ac.nz (Meyer, Tony)
Date: Sat, 9 Jul 2005 23:31:57 +1200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some
	RFEfor	review)
Message-ID: <ECBA357DDED63B4995F5C1F5CBE5B1E801B0F7C6@its-xchg4.massey.ac.nz>

>> Well, most people when confronted with this will rename the
>> directory to something simple like "ulib" and continue.
>
> I don't really buy this "trick": what if you happen to have
> a home directory with Unicode characters in it ?

I think this is one of the most common places, too.  Whenever I've come across unicode filenames it has been because the user has a unicode Windows username, so their 'home directory' (and temp directory, desktop folder, etc) does too.  Convincing people to either change their username or to go through the fairly complicated process of moving these directories elsewhere generally isn't feasible.

=Tony.Meyer

From mal at egenix.com  Sat Jul  9 19:43:54 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 09 Jul 2005 19:43:54 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE
	for	review)
In-Reply-To: <50862ebd0507090604290df5f6@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>	<ca471dc2050703112845321ad3@mail.gmail.com>	<50862ebd05070317183d971bef@mail.gmail.com>	<ca471dc205070400441ab49ffb@mail.gmail.com>	<50862ebd05070604117e9c5fb4@mail.gmail.com>
	<y88j3pqo.fsf@python.net>	<50862ebd05070805431808b7e5@mail.gmail.com>
	<wto1wdzv.fsf@python.net>	<50862ebd05070820506a829c45@mail.gmail.com>	<42CFAFBD.2010202@egenix.com>
	<50862ebd0507090604290df5f6@mail.gmail.com>
Message-ID: <42D00CDA.9000300@egenix.com>

Neil Hodgson wrote:
> M.-A. Lemburg:
> 
> 
>>I don't really buy this "trick": what if you happen to have
>>a home directory with Unicode characters in it ?
> 
> 
>    Most people choose account names and thus home directory names that
> are compatible with their preferred locale settings: German users are
> unlikely to choose an account name that uses Japanese characters.

It's naive to assume that all people in Germany using the German
locale have German names ;-) E.g. we have a large Japanese community
living here in D?sseldorf. If that example does not convince you,
just have a look at all the Chinese restaurants in cities around
the world - I'm sure that quite a few of the owners will want to
use their correctly written name as account name. Unicode makes
this possible and while it may not be in wide-spread use nowadays,
things will definitely change over the next few years as more and
more OSes and platforms will introduce native Unicode support.

> Unicode is only necessary for file names that are outside your default
> locale. An administration utility may need to visit multiple user's
> home directories and so is more likely to encounter files with names
> that can not be represented in its default locale.

I'm not sure why you bring up an administration tool: isn't
the discussion about being able to load Python modules from
directories with Unicode path components ?

>    I think it would be better if sys.path could include unicode
> entries but expect the code will rarely be exercised.

I think that sys.path should always use Unicode for non-ASCII
path names - this would make it locale setting independent, which
is what we should strive for in Py3k: locales are much easier to
handle at the application level and only introduce portability
problems if used at the OS or C lib level.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From gvanrossum at gmail.com  Sat Jul  9 20:21:04 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Sat, 9 Jul 2005 11:21:04 -0700
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <50862ebd0507090604290df5f6@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<50862ebd05070604117e9c5fb4@mail.gmail.com> <y88j3pqo.fsf@python.net>
	<50862ebd05070805431808b7e5@mail.gmail.com> <wto1wdzv.fsf@python.net>
	<50862ebd05070820506a829c45@mail.gmail.com>
	<42CFAFBD.2010202@egenix.com>
	<50862ebd0507090604290df5f6@mail.gmail.com>
Message-ID: <ca471dc205070911216a57ff6e@mail.gmail.com>

On 7/9/05, Neil Hodgson <nyamatongwe at gmail.com> wrote:
> M.-A. Lemburg:
> 
> > I don't really buy this "trick": what if you happen to have
> > a home directory with Unicode characters in it ?
> 
>    Most people choose account names and thus home directory names that
> are compatible with their preferred locale settings: German users are
> unlikely to choose an account name that uses Japanese characters.
> Unicode is only necessary for file names that are outside your default
> locale. An administration utility may need to visit multiple user's
> home directories and so is more likely to encounter files with names
> that can not be represented in its default locale.
> 
>    I think it would be better if sys.path could include unicode
> entries but expect the code will rarely be exercised.

Another problem is that if you can return 8-bit strings encoded in the
local code page, and also Unicode, combining the two using string
operations (e.g. a directory using the local code page containing a
file using Unicode, and then combining the two using os.path.join())
will fail unless the local code page is also Python's global default
encoding (which it usually isn't -- we really try hard to keep the
default encoding 'ascii' at all times).

In some sense the safest approach from this POV would be to return
Unicode as soon as it can't be encoded using the global default
encoding. IOW normally this would return Unicode for all names
containing non-ASCII characters.

The problem is of course that while the I/O functions will handle this
fine, *printing* Unicode still doesn't work by default. :-( I can't
wait until we switch everything to Unicode and have encoding on all
streams...

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

From ulrich.berning at t-online.de  Sun Jul 10 00:57:32 2005
From: ulrich.berning at t-online.de (Ulrich Berning)
Date: Sun, 10 Jul 2005 00:57:32 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <ur7e8f8zo.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>	<42CDA8F9.7080103@v.loewis.de>
	<ufyuqp2fm.fsf@boost-consulting.com>	<42CE0E10.6080509@v.loewis.de>
	<upsttn8yk.fsf@boost-consulting.com>	<42CEF46C.60509@v.loewis.de>
	<ubr5chj1h.fsf@boost-consulting.com>	<42CF88D3.9090005@t-online.de>
	<ur7e8f8zo.fsf@boost-consulting.com>
Message-ID: <42D0565C.7070000@t-online.de>

David Abrahams schrieb:

>Ulrich Berning <ulrich.berning at t-online.de> writes:
>
>  
>
>>If you build C++ extensions on HP-UX with aCC, Python must be compiled 
>>and linked as a C++ program. This is documented.
>>    
>>
>
>You mean dynamically loaded C++ extensions, or the kind that are
>linked into the Python executable?
>
>  
>
Dynamically loaded extensions, especially SIP/PyQt 
(http://www.riverbankcomputing.co.uk).

>I'm willing to believe almost anything about HP-UX.  Until recently,
>aCC was so broken as a C++ compiler that there was little point in
>trying to get Boost.Python to work on it, and I don't have much data
>for that system.
>
>  
>
I'm using the HP aC++ Compiler C.03.50 together with the patches 
PHSS_29483 and PHSS_30967 on HP-UX B.11.00 and had no problems to build 
Python (2.3.5), Qt, SIP and PyQt and all other extensions with it.

>>It will not work if Python is compiled and linked as a normal C
>>program (I have tried it).
>>    
>>
>
>Even if you take out the use of C++ constructs in ccpython.cc?  I just
>need to check all the obvious angles.
>
>  
>
What do you mean? The only C++ construct in ccpython.cc is the extern 
"C" declaration of Py_Main() and this is necessary if a C++ program 
references symbols from a C library. HP says, that a C++ shared library 
or a C++ shared object can only be loaded by a C++ main program. I can't 
remember the error message/symptoms, but I tried to build Python using 
python.c and couldn't load any C++ extensions. Because I'm going on 
vacation for the next three weeks, I can't try anything on HP-UX at the 
moment.

From dave at boost-consulting.com  Sun Jul 10 02:15:29 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 09 Jul 2005 20:15:29 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42D0565C.7070000@t-online.de> (Ulrich Berning's message of "Sun, 
	10 Jul 2005 00:57:32 +0200")
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CDA8F9.7080103@v.loewis.de> <ufyuqp2fm.fsf@boost-consulting.com>
	<42CE0E10.6080509@v.loewis.de> <upsttn8yk.fsf@boost-consulting.com>
	<42CEF46C.60509@v.loewis.de> <ubr5chj1h.fsf@boost-consulting.com>
	<42CF88D3.9090005@t-online.de> <ur7e8f8zo.fsf@boost-consulting.com>
	<42D0565C.7070000@t-online.de>
Message-ID: <ubr5becta.fsf@boost-consulting.com>

Ulrich Berning <ulrich.berning at t-online.de> writes:

> David Abrahams schrieb:
>
>>Ulrich Berning <ulrich.berning at t-online.de> writes:
>>
>>  
>>
>>> If you build C++ extensions on HP-UX with aCC, Python must be
>>> compiled and linked as a C++ program. This is documented.
>>>    
>>>
>>
>>You mean dynamically loaded C++ extensions, or the kind that are
>>linked into the Python executable?
>>
>>  
>>
> Dynamically loaded extensions, especially SIP/PyQt 
> (http://www.riverbankcomputing.co.uk).

I see.

>>I'm willing to believe almost anything about HP-UX.  Until recently,
>>aCC was so broken as a C++ compiler that there was little point in
>>trying to get Boost.Python to work on it, and I don't have much data
>>for that system.
>>
>>  
>>
> I'm using the HP aC++ Compiler C.03.50 together with the patches 
> PHSS_29483 and PHSS_30967 on HP-UX B.11.00 and had no problems to build 
> Python (2.3.5), Qt, SIP and PyQt and all other extensions with it.

Yeah, but Boost tends to stress a C++ compiler's correctness much more
than Qt.

>>>It will not work if Python is compiled and linked as a normal C
>>>program (I have tried it).
>>
>>Even if you take out the use of C++ constructs in ccpython.cc?  I just
>>need to check all the obvious angles.
>  
> What do you mean? The only C++ construct in ccpython.cc is the extern 
> "C" declaration of Py_Main() 

That's what I mean.

> and this is necessary if a C++ program 
> references symbols from a C library. HP says, that a C++ shared library 
> or a C++ shared object can only be loaded by a C++ main program. 

Well, that's dumb, but I believe it.

> I can't remember the error message/symptoms, but I tried to build
> Python using python.c and couldn't load any C++ extensions. Because
> I'm going on vacation for the next three weeks, I can't try anything
> on HP-UX at the moment.

Okay, I'm convinced that on HP/UX, Python needs to be a C++ program.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From martin at v.loewis.de  Sun Jul 10 09:12:07 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 09:12:07 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <ubr5chj1h.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>	<42CDA8F9.7080103@v.loewis.de>
	<ufyuqp2fm.fsf@boost-consulting.com>	<42CE0E10.6080509@v.loewis.de>
	<upsttn8yk.fsf@boost-consulting.com>	<42CEF46C.60509@v.loewis.de>
	<ubr5chj1h.fsf@boost-consulting.com>
Message-ID: <42D0CA47.2090101@v.loewis.de>

David Abrahams wrote:
> Yes, and that becomes important in programs that have constructors.
> I.e., C++ programs.  The Python executable is not such a program,
> except for one C++ file: ccpython.cc. 

That is not true. ccpython was introduced to support builds of
the Python interpreter where some modules are C++. As you know,
people do write extension modules in C++.

> There is no reason that file
> couldn't be rewritten as a pure 'C' file and any need for Python to be
> linked with G++ would disappear.

There is already a version of that file in C, Modules/python.c. This
is used when --with-cxx is not given.

>>The configure option --with-cxx (documented as "enable C++ support")
>>make Python C++ options work on such systems.
> 
> 
> What are "Python C++ options?"

Oops, meant "Python C++ extension modules" (it must have been late when
I wrote that).

>>I could personally accept if ccpython and --with-cxx would be dropped
>>entirely (i.e. deliberately breaking systems which require it); 
> 
> 
> I don't believe any systems require it.  I realize you have said
> otherwise, but after years of working with Boost.Python I'm very
> familiar with the issues of dynamic linking and C/C++ interoperability
> on a wide variety of platforms, and I'm not convinced by your
> assertion.  If such a system exists, it should be easy for someone to
> point me at it, and show that something breaks.

I well remember that gcc 2.5.8 on Linux a.out required this sort of
setup. Dynamic linking was not supported at all on that system (atleast
not in a way where users could easily write shared libraries
themselves). Rebuilding the Python interpreter was the only option
to integrate additional modules.

Regards,
Martin

From martin at v.loewis.de  Sun Jul 10 09:21:23 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 09:21:23 +0200
Subject: [Python-Dev] GCC version compatibility
In-Reply-To: <u3bqohi6z.fsf@boost-consulting.com>
References: <u8y0jz762.fsf@boost-consulting.com>	<42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>	<u8y0hl45u.fsf@boost-consulting.com>
	<42CEF948.3010908@v.loewis.de> <u3bqohi6z.fsf@boost-consulting.com>
Message-ID: <42D0CC73.90407@v.loewis.de>

David Abrahams wrote:
>>I'll describe it once more: *If* a program is compiled with the C++
>>compiler, is it *then* possible to still link it with the C compiler?
>>This is the question this test tries to answer.
> 
> 
> Okay, I understand that.  What I have never understood is why that
> should be an appropriate thing to test for the Python executable.
> There's no reason to compile any of Python with a C++ compiler.

I hope you understand now: it is necessary if you want to link
C++ extension modules into a Python interpreter (statically, not
dynamically).

>>Wrong. The test was introduced in response to complaints that Python
>>unnecessarily links with libstdc++ on some Linux systems. 
> 
> 
> Apparently it still does.

Not "still", but "again", since recent changes in gcc.

>>On these Linux systems, it was well possible to build main() with a
>>C++ compiler
> 
> 
> Nobody would need to build Python's main() with a C++ compiler, if
> you'd just comment out the 'extern "C"'.

Wrong. People that statically link C++ extensions modules on systems
where the C++ compiler requires main to be compiled as C++ need
to do such a thing. One such compiler is gcc on systems where the
binary format does not support .init sections.

>>and still link the entire thing with gcc. Since main() doesn't use
>>any libstdc++ functionality, and since collect2/__main isn't used,
>>one would indeed expect that linking with CXX is not necessary.
> 
> 
> It isn't.

Hmmm. It is. Try for yourself. You get an unresolved gxx_personality_v0.

> I have tested Boost.Python and C++ extension modules on a wide variety
> of Linux systems, and have seen this phenomenon.

Did you try on Linux systems released 1994? That don't use ELF as
the binary format?

> I think either the ELF Linux loader changed substantially since 1995,
> or whoever introduced this test was just confused.

No. The ELF loader was *introduced* since 1995. Dynamic loading was
not available before.

Regards,
Martin

From martin at v.loewis.de  Sun Jul 10 09:25:51 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 09:25:51 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <uy88gg399.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CD3052.6000704@acm.org>	<uy88ivgg0.fsf@boost-consulting.com>	<17101.16300.736797.378762@montanaro.dyndns.org>	<ud5putpjj.fsf@boost-consulting.com>	<17101.37403.452222.396424@montanaro.dyndns.org>	<upstup7r9.fsf@boost-consulting.com>
	<42CEFE31.1000800@v.loewis.de> <uy88gg399.fsf@boost-consulting.com>
Message-ID: <42D0CD7F.3080007@v.loewis.de>

David Abrahams wrote:
>>Not entirely. By extending Modules/Setup 
> 
> 
> You mean 
> http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/Setup.dist?view=markup
> ?

I mean Modules/Setup. It is generated from Modules/Setup.dist
(plus some additional information) in the build process.

> I contend that either:
> 
>    a.  Anyone making that sort of extension with a C++ module should
>    explicitly request --with-cxx, or
> 
>    b.  The python build system should automatically detect that
>    --with-cxx is needed based on the presence of C++ extension
>    modules.
> 
> Frankly I think b. would require an impractical amount of work and,
> speaking as an author of C++ extension modules, I don't think a. is
> much of a burden to impose.

It is the burden of change. Contributions are welcome.

However, you will find that with a), people will still pass --with-cxx,
because they tend to "enable" all features they can find.

I personally could accept --with-cxx and ccpython.cc to be removed
again, but I'm uncertain whether that may break distutils in some way.

Regards,
Martin

From martin at v.loewis.de  Sun Jul 10 09:45:25 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 09:45:25 +0200
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
In-Reply-To: <20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de>	<uu0j6p7z1.fsf@boost-consulting.com>	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>	<u8y0hl45u.fsf@boost-consulting.com>
	<42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <42D0D215.9000708@v.loewis.de>

Christoph Ludwig wrote:
>>I'll describe it once more: *If* a program is compiled with the C++
>>compiler, is it *then* possible to still link it with the C compiler?
>>This is the question this test tries to answer.
> 
> 
> The keyword here is "tries"

Any such test would only "try": to really determine whether this is
necessary for all possible programs, one would have to test all possible
programs. Since there is an infinite number of programs, this test could
take a while.

The original test, on the original system, would cause __main to be
undefined, and then decide to use C++. For a long time, on systems
that don't use collect2, the test *correctly* determined that linking
with g++ was not necessary.

It is only recent changes to g++ that break the test, namely the
introduction of this __gxx_personality_v0 thing.


> - my bug report #1189330 exihibts that the test
> fails to do its job. And looking at the test that's certainly no surprise:

However, it *is* a surprise that your modified test fixes the problem.

> Note that there is *no* reference to any symbol in another TU. The compiler
> can detect that foo() won't throw any exceptions, that there is no need for RTTI
> and whatever else the C++ runtime provides. Consequently, the object file
> produced by g++ does not contain any reference to symbols in libstdc++.

You are assuming implementation details here. I have seen
implementations of C++ (eg. g++ with collect2) where the test determines
that linking with C++ is necessary (because __main was undefined), as
well as systems where the test decides *correctly* that linking with
C++ is not necessary (e.g. gcc 2.x on an ELF system). That some C++
compiler introduces the C++ runtime if some C function may throw an
exception is a very specific detail of this C++ compiler.

> Of course, if you insist on this "dependency optimization" then you can try to
> fix Python's configure.in by using the second test above. But I would still
> not trust it to cover all configurations on all platforms supported by
> Python. 

Of couse not. This is just autoconf: it does not allow magical porting
to all possible future operating systems. Instead, from time to time,
explicit porting activity is necessary. This is not just about this
specific detail, but about many other details. Each new operation
system, library, or compiler version might break the build process.

> Can you provide a concrete examples of such systems? The explanation of
> --with-cxx in the README mentions a.out. Are there other systems?

I'm not sure. I think HP-UX (with OMF, and aCC) might have required
the same code, as may have SysVR3 (with COFF).

Regards,
Martin

From fpillet at gmail.com  Sun Jul 10 11:29:08 2005
From: fpillet at gmail.com (Florent Pillet)
Date: Sun, 10 Jul 2005 11:29:08 +0200
Subject: [Python-Dev] C bindings calling tmpfile() blocks interrupt
	signal
In-Reply-To: <2mhdf6vkls.fsf@starship.python.net>
References: <d143d3ff0507070517154ec286@mail.gmail.com>
	<2mhdf6vkls.fsf@starship.python.net>
Message-ID: <d143d3ff05071002292f49cac7@mail.gmail.com>

On 07/07/05, Michael Hudson <mwh at python.net> wrote:
>>
> > But with my threaded Python code, SIGINT doesn't work anymore after my
> > binding has called tmpfile().
> 
> Oh, threads.
> 
> Which version of Python are you using?

2.3.5, the one that ships with Mac OS X 10.4. I have a 2.4.x install
somewhere, I'll give it a go. But you're right, it's probably because
of threads. Now I'm trying to determine whether this is a Python bug
or a Mac OS X bug...

Florent

-- 
Florent Pillet                  http://www.florentpillet.com
Freelance software developer/consultant - Palm OS & Mac OS X
ICQ: 117292463                Skype: callto://florent.pillet

From adurdin at gmail.com  Sun Jul 10 13:21:48 2005
From: adurdin at gmail.com (Andrew Durdin)
Date: Sun, 10 Jul 2005 21:21:48 +1000
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <42CBCF64.1090106@gmail.com>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
	<dafs0o$4fm$1@sea.gmane.org>
	<59e9fd3a0507060236cddc3ba@mail.gmail.com>
	<59e9fd3a05070602451125d803@mail.gmail.com>
	<42CBCF64.1090106@gmail.com>
Message-ID: <59e9fd3a050710042125965fd6@mail.gmail.com>

On 7/6/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> However, while I prefer what you describe to Python's current
> behaviour, I am not yet convinced the backward compatibility pain is
> worth it. Adding yet-another-kind-of-string-literal (when we already
> have bytestrings on the horizon) is also unappealing.

First off, thanks for your feedback--you raise some very good points
that I have addressed insufficiently or not at all.

I personally feel that backward compatibility issues provide the
strongest argument against accepting the proposal (but obviously I
find the rest of it favourable :-).  It may not be particularly clear
(that's why it's a draft) that I am not proposing another kind of
string literal, but rather a change of rules for an existing one.
 
> Your readability examples are good, but the first two involve strings
> that should probably be module level constants (as Terry described)
> and the test case involving expected output is probably better handled
> using doctest, which has its own mechanism for handling indentation.

I think the question of whether an inline string should be made a
module-level constant (or moved to a separate file entirely) relates
in general to higher-level considerations of readability and program
structure (similar, for example, to those that would prompt one to
refactor a function). IOW, the answer to that question would be the
same with or without this proposal. In any case, I chose the examples
(from different parts of the standard library) more because they
illustrated different classes of usage for TQS's than because they
were the best illustrations of readability improvement--perhaps
something I should address.

> Raw and unicode string literals need to be mentioned in the PEP. Which
> literals would the reformatting apply to? All 3? Only standard and
> unicode, leaving raw strings alone?

The proposal would apply to all 4 :-) -- normal, raw, unicode, and raw unicode.

> You should research the reasons why PEP 295 [1] was rejected, and
> describe in the new PEP how it differs from PEP 295 (unfortunately PEP
> 295 was not updated with the rationale for rejection, but this post
> [2] looks like Guido putting the final nail in its coffin).

THANK YOU! In my research for this, I didn't come across PEP 295 at
all -- perhaps due to the fact that it uses the term "multiline
strings" exclusively, which is not how I would describe them at all. 
I will certainly address this in my next draft.

Cheers,

Andrew.

From adurdin at gmail.com  Sun Jul 10 13:27:40 2005
From: adurdin at gmail.com (Andrew Durdin)
Date: Sun, 10 Jul 2005 21:27:40 +1000
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <ca471dc2050706081361f64dfc@mail.gmail.com>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
	<ca471dc2050706081361f64dfc@mail.gmail.com>
Message-ID: <59e9fd3a05071004277905fbf9@mail.gmail.com>

On 7/7/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> 
> I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI.

In what way? The scheme described is explicit, and consistently
applied to all triple-quoted strings[*] -- although the rules are
different to the current behaviour. On the other hand, my written
proposal may not be clear or explicit, something I will attempt to
remedy over the next few days.

[*] Whether it should apply also to normal strings with escaped
newlines is not something I have yet considered.

Andrew

From adurdin at gmail.com  Sun Jul 10 13:38:45 2005
From: adurdin at gmail.com (Andrew Durdin)
Date: Sun, 10 Jul 2005 21:38:45 +1000
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <dah7iv$96i$1@sea.gmane.org>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
	<dafs0o$4fm$1@sea.gmane.org>
	<59e9fd3a0507060236cddc3ba@mail.gmail.com>
	<59e9fd3a05070602451125d803@mail.gmail.com>
	<dah7iv$96i$1@sea.gmane.org>
Message-ID: <59e9fd3a050710043860e29567@mail.gmail.com>

On 7/7/05, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> I believe there were some current alternatives and concerns already
> expressed that have not been included yet that maybe should be.

Yes; Nick pointed me to one, and I'll be looking at that and the
related discussions before redrafting; I'll also have a further look
for other similar proposals.
 
> Some of your examples look worse than needed by putting the first line
> after the triple quote instead of escaping the first newline like you did
> elsewhere.

In general, I wanted to preserve as much as possible the way that the
string was originally written (as these examples were taken and
adapted from the standard library source).  In the example with the
embedded python code, I felt it was significantly clearer if the
initial newline was escaped.

> Having separate rules for doc strings and other tq strings would be a
> nuisance.

I totally agree -- and if the proposal as written gives that
impression then I'll correct it. What I was trying to say about
docstrings was that the change would have no effect on the result
after processing them with docutils or anything else that follows PEP
257 -- which is very significant in terms of backward compatibility,
as docstrings are AFAICT the leading use of TQS's (by a large margin).

Cheers,

Andrew.

From reinhold-birkenfeld-nospam at wolke7.net  Sun Jul 10 14:25:58 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Sun, 10 Jul 2005 14:25:58 +0200
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <ca471dc2050706081361f64dfc@mail.gmail.com>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
	<ca471dc2050706081361f64dfc@mail.gmail.com>
Message-ID: <dar44m$86h$1@sea.gmane.org>

Guido van Rossum wrote:
> On 7/5/05, Andrew Durdin <adurdin at gmail.com> wrote:
>> I have written a patch that changes the way triple-quoted strings are
>> scanned so that leading whitespace is ignored in much the same way
>> that pep 257 handles it for docstrings. Largely this was for a
>> learning experience in hacking the parser, but it would be very nice
>> IMO if something of this sort could be implemented in a future version
>> of Python.
> 
> I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI.

Another idea, which is much more conservative: textwrap.dedent is highly under-
rated and hidden. Why not make it builtin or a string method?

Reinhold

-- 
Mail address is perfectly valid!


From dave at boost-consulting.com  Sun Jul 10 15:14:04 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 10 Jul 2005 09:14:04 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42D0CA47.2090101@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sun, 10 Jul 2005 09:12:07 +0200")
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CDA8F9.7080103@v.loewis.de> <ufyuqp2fm.fsf@boost-consulting.com>
	<42CE0E10.6080509@v.loewis.de> <upsttn8yk.fsf@boost-consulting.com>
	<42CEF46C.60509@v.loewis.de> <ubr5chj1h.fsf@boost-consulting.com>
	<42D0CA47.2090101@v.loewis.de>
Message-ID: <uirzidcrn.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

>> I don't believe any systems require it.  I realize you have said
>> otherwise, but after years of working with Boost.Python I'm very
>> familiar with the issues of dynamic linking and C/C++ interoperability
>> on a wide variety of platforms, and I'm not convinced by your
>> assertion.  If such a system exists, it should be easy for someone to
>> point me at it, and show that something breaks.
>
> I well remember that gcc 2.5.8 on Linux a.out required this sort of
> setup. 

Sorry, a.out?  Isn't that the default name a C compiler gives to the
executable it builds on Unix?  Is it also (part of) the name of an OS?

> Dynamic linking was not supported at all on that system (atleast
> not in a way where users could easily write shared libraries
> themselves). Rebuilding the Python interpreter was the only option
> to integrate additional modules.

Understood, and I retract my former incredulity.  I believe HP-UX
requires it, and I believe that some systems where you have to link in
extension modules explicitly require it.  But the "--with-cxx if
configure says you can get away with it" behavior is hurting on a
major platform: ELF Linux.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From p.f.moore at gmail.com  Sun Jul 10 15:16:59 2005
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 10 Jul 2005 14:16:59 +0100
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <uirzidcrn.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com> <42CDA8F9.7080103@v.loewis.de>
	<ufyuqp2fm.fsf@boost-consulting.com> <42CE0E10.6080509@v.loewis.de>
	<upsttn8yk.fsf@boost-consulting.com> <42CEF46C.60509@v.loewis.de>
	<ubr5chj1h.fsf@boost-consulting.com> <42D0CA47.2090101@v.loewis.de>
	<uirzidcrn.fsf@boost-consulting.com>
Message-ID: <79990c6b050710061621ab9755@mail.gmail.com>

On 7/10/05, David Abrahams <dave at boost-consulting.com> wrote:
> "Martin v. L?wis" <martin at v.loewis.de> writes:
> > I well remember that gcc 2.5.8 on Linux a.out required this sort of
> > setup.
> 
> Sorry, a.out?  Isn't that the default name a C compiler gives to the
> executable it builds on Unix?  Is it also (part of) the name of an OS?

It's the name of an executable format that predates ELF. I don't know
if it's in current use anywhere.

Paul.

From dave at boost-consulting.com  Sun Jul 10 15:30:02 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 10 Jul 2005 09:30:02 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42D0CD7F.3080007@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sun, 10 Jul 2005 09:25:51 +0200")
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
Message-ID: <ueka6dc11.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>>>Not entirely. By extending Modules/Setup 
>> 
>> 
>> You mean 
>> http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/Setup.dist?view=markup
>> ?
>
> I mean Modules/Setup. It is generated from Modules/Setup.dist
> (plus some additional information) in the build process.
>
>> I contend that either:
>> 
>>    a.  Anyone making that sort of extension with a C++ module should
>>    explicitly request --with-cxx, or
>> 
>>    b.  The python build system should automatically detect that
>>    --with-cxx is needed based on the presence of C++ extension
>>    modules.
>> 
>> Frankly I think b. would require an impractical amount of work and,
>> speaking as an author of C++ extension modules, I don't think a. is
>> much of a burden to impose.
>
> It is the burden of change. 

Well, as you say:

  What *has* changed now is that the configure test suddenly determines
  that you need to link with g++ on Linux if main was compiled with g++.
  This was not the case before, but now is (since g++ 3.2 or something).

> Contributions are welcome.

Let me first try to discover what contribution would be acceptable.
What if:

  - we add a configure test that runs after the existing test
    determines that --with-cxx is needed (but not when --with-cxx is
    explicitly specified on the command line)

  - This test runs a 'C' executable that tries to load a C++ dynamic
    library with dlopen.  

  - The test returns an error code if the the dynamic library's static
    and dynamic initializers have not been run properly

  - If the test fails we disable --with-cxx

??

I'm trying to intrude on the existing behavior as little as possible,
yet get the semantics we want for ELF/Linux in a way that stands a
good chance of generalizing to other platforms.

> However, you will find that with a), people will still pass --with-cxx,
> because they tend to "enable" all features they can find.

That's acceptable to me.  We could probably circumvent some of those
cases by improving the configure --help text.

> I personally could accept --with-cxx and ccpython.cc to be removed
> again, but I'm uncertain whether that may break distutils in some
> way.

Well, that would certainly be an easy "solution," but it would break
HP/UX, and it would break anyone that needs to statically link C++
modules on some platforms.  It's a much more drastic change than it
would be to only have the system use --with-cxx when the person
running configure asks for it explicitly.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From dave at boost-consulting.com  Sun Jul 10 15:38:35 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 10 Jul 2005 09:38:35 -0400
Subject: [Python-Dev] GCC version compatibility
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <uzmsubx2c.fsf@boost-consulting.com>

Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:

> --with-cxx=<compiler>: If you plan to use C++ extension modules, then on some
>         platform you need to compile python's main() function with the C++
>         compiler. With this option, make will use <compiler> to compile main()
>         *and* to link the python executable. It is likely that the resulting
>         executable depends on the C++ runtime library of <compiler>.
>
>         Note there are platforms that do not require you to build Python with
>         a C++ compiler in order to use C++ extension modules. E.g., x86 Linux
>         with ELF shared binaries and GCC 3.x, 4.x is such a platform. We
>         recommend that you configure Python --without-cxx on those platforms
>         to avoid unnecessary dependencies.

I don't think that's strong enough.  What happens is that dynamically
loaded Python extension modules built with other, ABI-compatible
versions of G++ may *crash*.

>         If you need to compile main() with <compiler>, but your platform does
>         not require that you also link the python executable with <compiler> 
>         (e.g., <example platform>), then set LINKCC='$(PURIFY) $(CC)' prior to
>         calling make. Then the python executable will not depend on the C++
>         runtime library of <compiler>.

Are we sure we have an actual use case for the above?  Doesn't
--without-cxx cover all the actual cases we know about?

> BTW, I'd also change the short explanation output by `configure --help'.
> Something like:
>
>   AC_HELP_STRING(--with-cxx=<compiler>, 
>                  use <compiler> to compile and link main())
>
> In Python 2.4.1, the help message says "enable C++ support". That made me use
> this option even though it turned out it is not necessary on my platform.

Your suggestion is simple and powerful; I like it!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


From dave at boost-consulting.com  Sun Jul 10 15:35:33 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 10 Jul 2005 09:35:33 -0400
Subject: [Python-Dev] GCC version compatibility
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <u64vidbru.fsf@boost-consulting.com>

Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:

> I do not claim the 2 TUs test will cover all possible scenarios. I am not even
> sure this decision should be left to an automated test. Because if the test
> breaks for some reason then the user is left with a linker error that is
> time-consuming to track down.

However, at least by the usual hierarchy of values, the sort of
runtime error that results from the current needless linking with C++
on ELF/Linux is even worse.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


From rwgk at yahoo.com  Sun Jul 10 16:13:02 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 10 Jul 2005 07:13:02 -0700 (PDT)
Subject: [Python-Dev] [C++-sig]    GCC version compatibility
In-Reply-To: <u64vidbru.fsf@boost-consulting.com>
Message-ID: <20050710141302.73934.qmail@web31507.mail.mud.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:

> Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:
> 
> > I do not claim the 2 TUs test will cover all possible scenarios. I am not
> even
> > sure this decision should be left to an automated test. Because if the test
> > breaks for some reason then the user is left with a linker error that is
> > time-consuming to track down.
> 
> However, at least by the usual hierarchy of values, the sort of
> runtime error that results from the current needless linking with C++
> on ELF/Linux is even worse.

Indeed. A few months ago the current configure behavior lead to a major loss of
our time, probably a whole week between 4-5 people.
The problem was that a Python compiled under RH 8.0 was used to build and run
new C++ extensions under Fedroa Core 3. Some extensions ran OK, others crashed
without warning after running to a certain point. It was very confusing.
To avoid this situation in the future, we permanently added a test to our setup
scripts, comparing the result of ldd python | grep libstdc++ to the
corresponding output for extension modules.

Cheers,
        Ralf


		
____________________________________________________
Sell on Yahoo! Auctions ? no fees. Bid on great items.  
http://auctions.yahoo.com/

From jcarlson at uci.edu  Sun Jul 10 18:23:54 2005
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sun, 10 Jul 2005 09:23:54 -0700
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <59e9fd3a05071004277905fbf9@mail.gmail.com>
References: <ca471dc2050706081361f64dfc@mail.gmail.com>
	<59e9fd3a05071004277905fbf9@mail.gmail.com>
Message-ID: <20050710084923.713E.JCARLSON@uci.edu>


Andrew Durdin <adurdin at gmail.com> wrote:
> 
> On 7/7/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> > 
> > I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI.
> 
> In what way? The scheme described is explicit, and consistently
> applied to all triple-quoted strings[*] -- although the rules are
> different to the current behaviour. On the other hand, my written
> proposal may not be clear or explicit, something I will attempt to
> remedy over the next few days.

You are wrong.  Current string literals are explicit.  They are what you
type.  What you propose is to force all string literals to be
/implicitly/ preprocessed by the compiler, an operation that
/necessarily/ loses information.

The current mechanism that works behind the scenes for docstrings does
/no/ preprocessing of string literals used as docstrings*.  Why? Because
the designers realized that doing so may break source that relies on
those docstrings for precise indentation.

Right now, your (implicit preprocessing of triple quoted strings)
proposal may change the output of various report generation softwares. 
Specifically, ones who use a 'header-line' for the names of columns...

print '''
        column      column      column'''


> [*] Whether it should apply also to normal strings with escaped
> newlines is not something I have yet considered.

When you have to start differentiating, or consider differentiating, how
preprocessing occurs based on the existance or non-existance of escaped
newlines, you should realize that this has a serious "Do what I mean"
stink (as Guido has already stated, more politely).


I propose that we keep all string literals /literal/, not only those
lacking triple-quoting.  Any processing that needs to be done to /any/
string (literal or otherwise), should be explicitly asked for.  Is that
too much to ask?


 - Josiah


[*]
>>> def foo():
...     '''
...         x
...             y
...           z
...     '''
...
>>> help(foo)
Help on function foo in module __main__:

foo()
    x
        y
      z

>>> print foo.__doc__

        x
            y
          z

>>>


From martin at v.loewis.de  Sun Jul 10 19:41:06 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 19:41:06 +0200
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
In-Reply-To: <20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <42D15DB2.3020300@v.loewis.de>

Christoph Ludwig wrote:
> My point is: The test implemented in the 2.4.1 configure script gives a wrong
> result if your platform happens to be x86 Linux with ELF binaries and 
> g++ 4.0. 

Point well taken.

>>It is only recent changes to g++ that break the test, namely the
>>introduction of this __gxx_personality_v0 thing.
> 
> 
> The test broke due to a change in GCC 4.0, but the "__gxx_personality_v0
> thing" was introduced long before. It is merely a symptom. I ran the tests
> with GCC 3.3.1, 3.4.2, and 4.0.0. Here are the results:

As I say: it's a recent change (GCC 3.3 *is* recent).

>>You are assuming implementation details here. 
> 
> I am not aware of any rule that makes the following program ill-formed:

And I didn't suggest that such a rules exists. Your proposed
modification to the test program is fine with me.

> But I digress. It's not that important for our discussion whether a C++
> compiler must / should / is allowed to add exception handling code to the
> call of an extern "C" function. The point is that some do *unless* they see
> the function definition. I contend the test involving two TUs matches more
> closely the situation with ccpython.cc than the current test.

Maybe. For Python 2.4, feel free to contribute a more complex test. For
Python 2.5, I would prefer if the entire code around ccpython.cc was
removed.

> Instead of having yet another test in configure.in that may break on a new
> platform and that needs maintenance wouldn't it be better to assume that
> --with-cxx implies linking with the C++ compiler and telling users how to
> override this assumption? Would it cause so much inconvenience to users
> provided the explanation of --with-cxx in the README would be modified?

*If* the configure algorithm is modified, I think I would prefer if the
feature was removed entirely.

> In Python 2.4.1, the help message says "enable C++ support". That made me use
> this option even though it turned out it is not necessary on my platform.

For 2.4.2, things should essentially stay the way they are, except
perhaps for fixing bugs. For 2.5, more radical changes are possible.

Regards,
Martin

From martin at v.loewis.de  Sun Jul 10 19:53:31 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 19:53:31 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <uirzidcrn.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>	<42CDA8F9.7080103@v.loewis.de>
	<ufyuqp2fm.fsf@boost-consulting.com>	<42CE0E10.6080509@v.loewis.de>
	<upsttn8yk.fsf@boost-consulting.com>	<42CEF46C.60509@v.loewis.de>
	<ubr5chj1h.fsf@boost-consulting.com>	<42D0CA47.2090101@v.loewis.de>
	<uirzidcrn.fsf@boost-consulting.com>
Message-ID: <42D1609B.9030805@v.loewis.de>

David Abrahams wrote:
>>I well remember that gcc 2.5.8 on Linux a.out required this sort of
>>setup. 
> 
> 
> Sorry, a.out?  Isn't that the default name a C compiler gives to the
> executable it builds on Unix?  Is it also (part of) the name of an OS?

Yes, and somewhat. It is also the name of a binary format, see
/usr/include/a.out.h (*). There are different types of object files:
OMAGIC (.o), NMAGIC,ZMAGIC,QMAGIC (executable), CMAGIC (core file). The
Linux inplementation is now called binfmt_aout, but it used to be the
only binary format that Linux supported up to Linux 1.2 (which
introduced ELF in 1.1.52). Originally, a.out did not support shared
libraries, but was extended to do so by allocating fixed virtual
addresses to well-known shared libraries, so that no relocation was
necessary (the a.out dynamic loader did not support either dynamic
relocation nor PIC code on Linux; the SunOS dynamic linker did support
relocation AFAIR).

Even after Linux implemented ELF, it took some time for distributions
to switch to ELF. Because of the startup overhead, there was some
reluctance that ELF is "slower"; it also created larger executables.
Only when developers realized how powerful dynamic linking and
shared libraries are, they gave up their concerns.

> Understood, and I retract my former incredulity.  I believe HP-UX
> requires it, and I believe that some systems where you have to link in
> extension modules explicitly require it.  But the "--with-cxx if
> configure says you can get away with it" behavior is hurting on a
> major platform: ELF Linux.

Indeed.

Regards,
Martin

(*) Actually, the format is called this way *because* it is the format
of the compiler output file.

From martin at v.loewis.de  Sun Jul 10 23:09:49 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Jul 2005 23:09:49 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <ueka6dc11.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CD3052.6000704@acm.org>	<uy88ivgg0.fsf@boost-consulting.com>	<17101.16300.736797.378762@montanaro.dyndns.org>	<ud5putpjj.fsf@boost-consulting.com>	<17101.37403.452222.396424@montanaro.dyndns.org>	<upstup7r9.fsf@boost-consulting.com>
	<42CEFE31.1000800@v.loewis.de>	<uy88gg399.fsf@boost-consulting.com>
	<42D0CD7F.3080007@v.loewis.de> <ueka6dc11.fsf@boost-consulting.com>
Message-ID: <42D18E9D.8040701@v.loewis.de>

David Abrahams wrote:
>   - we add a configure test that runs after the existing test
>     determines that --with-cxx is needed (but not when --with-cxx is
>     explicitly specified on the command line)
> 
>   - This test runs a 'C' executable that tries to load a C++ dynamic
>     library with dlopen.  
> 
>   - The test returns an error code if the the dynamic library's static
>     and dynamic initializers have not been run properly
> 
>   - If the test fails we disable --with-cxx
> 
> ??

What would be the purpose of such a test? The test may fail for many
reasons, for example, dlopen might not be available.

OTOH, on current Linux systems the test would succeed, so configure
would conclude to link with g++.

> I'm trying to intrude on the existing behavior as little as possible,
> yet get the semantics we want for ELF/Linux in a way that stands a
> good chance of generalizing to other platforms.

I now think that the code should be made more simple, not more complex.
Aspects of a solution I could accept:

- ccpython.cc and linking with g++ is removed entirely. or,
- the logic is fixed so that linking with g++ is only done if
  main is in ccpython.o
- the configure test is extended to better match current g++
  behaviour.

> Well, that would certainly be an easy "solution," but it would break
> HP/UX, and it would break anyone that needs to statically link C++
> modules on some platforms.  It's a much more drastic change than it
> would be to only have the system use --with-cxx when the person
> running configure asks for it explicitly.

I just checked, and it seems that the logic in use is still somewhat
different. If the configure test determines that a C++ main()
must be linked with CXX, it unconditionally changes the linker to CXX.
The test, in turn, is run always if a C++ compiler was found,
i.e. independently of whether --with-cxx was provided.

Regards,
Martin



From gvanrossum at gmail.com  Mon Jul 11 00:41:02 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Sun, 10 Jul 2005 15:41:02 -0700
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <59e9fd3a05071004277905fbf9@mail.gmail.com>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>
	<ca471dc2050706081361f64dfc@mail.gmail.com>
	<59e9fd3a05071004277905fbf9@mail.gmail.com>
Message-ID: <ca471dc20507101541743375b1@mail.gmail.com>

On 7/10/05, Andrew Durdin <adurdin at gmail.com> wrote:
> On 7/7/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> >
> > I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI.
> 
> In what way? The scheme described is explicit, and consistently
> applied to all triple-quoted strings[*] -- although the rules are
> different to the current behaviour. On the other hand, my written
> proposal may not be clear or explicit, something I will attempt to
> remedy over the next few days.

The scheme may be explicitly spelled out in the language reference,
but it is implicit to the human reader -- what you see is no longer
what you get.

> [*] Whether it should apply also to normal strings with escaped
> newlines is not something I have yet considered.

I recommend that you give it up. You ain't gonna convince me.

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

From dave at boost-consulting.com  Mon Jul 11 00:51:55 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 10 Jul 2005 18:51:55 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42D18E9D.8040701@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sun, 10 Jul 2005 23:09:49 +0200")
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
	<ueka6dc11.fsf@boost-consulting.com> <42D18E9D.8040701@v.loewis.de>
Message-ID: <uwtny8eb8.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>>   - we add a configure test that runs after the existing test
>>     determines that --with-cxx is needed (but not when --with-cxx is
>>     explicitly specified on the command line)
>> 
>>   - This test runs a 'C' executable that tries to load a C++ dynamic
>>     library with dlopen.  
>> 
>>   - The test returns an error code if the the dynamic library's static
>>     and dynamic initializers have not been run properly
>> 
>>   - If the test fails we disable --with-cxx
>> 
>> ??
>
> What would be the purpose of such a test? The test may fail for many
> reasons, for example, dlopen might not be available.

I was assuming we only disable --with-cxx if the test builds
successfully.  I presume dlopen will fail linking if it's unavailable?

> OTOH, on current Linux systems the test would succeed, so configure
> would conclude to link with g++.

Uhh, whoops. Change the sense of my last bullet

   - If the test passes we disable --with-cxx

>> I'm trying to intrude on the existing behavior as little as possible,
>> yet get the semantics we want for ELF/Linux in a way that stands a
>> good chance of generalizing to other platforms.
>
> I now think that the code should be made more simple, not more complex.
> Aspects of a solution I could accept:
>
> - ccpython.cc and linking with g++ is removed entirely. or,

That would be bad for C++ users on HP/UX.  Is that acceptable?

> - the logic is fixed so that linking with g++ is only done if
>   main is in ccpython.o

I don't see how that works.  Somehow we need to decide whether to put
main in ccpython.o in the first place, don't we?

> - the configure test is extended to better match current g++
>   behaviour.

What do you have in mind?

>> Well, that would certainly be an easy "solution," but it would break
>> HP/UX, and it would break anyone that needs to statically link C++
>> modules on some platforms.  It's a much more drastic change than it
>> would be to only have the system use --with-cxx when the person
>> running configure asks for it explicitly.
>
> I just checked, and it seems that the logic in use is still somewhat
> different. If the configure test determines that a C++ main()
> must be linked with CXX, it unconditionally changes the linker to CXX.
> The test, in turn, is run always if a C++ compiler was found,
> i.e. independently of whether --with-cxx was provided.

That doesn't match up with reports from my testers who say they can
run with C++ extension modules from many different GCC versions if
they just configure their Python --without-cxx.  If what you were
saying were true, wouldn't --without-cxx be ignored on ELF/Linux?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From adurdin at gmail.com  Mon Jul 11 05:27:53 2005
From: adurdin at gmail.com (Andrew Durdin)
Date: Mon, 11 Jul 2005 13:27:53 +1000
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <20050710084923.713E.JCARLSON@uci.edu>
References: <ca471dc2050706081361f64dfc@mail.gmail.com>
	<59e9fd3a05071004277905fbf9@mail.gmail.com>
	<20050710084923.713E.JCARLSON@uci.edu>
Message-ID: <59e9fd3a050710202721851037@mail.gmail.com>

On 7/11/05, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> You are wrong.  Current string literals are explicit.  They are what you
> type.

No they are not:

    >>> "I typed \x41, but got this!"
    'I typed A, but got this!'

What we have are not explicit string literals but *explicit rules*,
forming part of the language definition and given in the documentation
that certain sequences in string literals are preprocessed by the
compiler.  People have learnt these rules and apply them unconsciously
when reading the source--but that can apply to any rule. For example,
there's another explicit rule, that an "r" prefixed before the string
literal uses a different set of rules without \-escape sequences:

    >>> r"I typed \x41, but got this!"
    'I typed \\x41, but got this!'

The point is that processing \-escape sequences is just as implicit as
my proposal: but tradition, and custom, and documentation make it
*seem* explicit of itself. IOW, arguing that my proposal is "implicit"
or "DWIM" is neither relevant nor valid--but arguing either that it is
confusing to a long-term Python user, or that it is not fully backward
compatible is valid, and these (and other) arguments against should be
weighed up against those in favour. (Even some fairly recent and major
changes to Python have been accepted despite having these two
particular arguments against them, such as unified classes/types and
nested scopes).

> When you have to start differentiating, or consider differentiating, how
> preprocessing occurs based on the existance or non-existance of escaped
> newlines, you should realize that this has a serious "Do what I mean"
> stink (as Guido has already stated, more politely).

What I am considering differentiating on here is a feature of Python
that is (at least) awkward and (at most) has a "serious stink" -- the
ability to escape newlines in a single-quoted [' or "] string with a
backslash, which has inconsistent or confusing behaviour:

    >>> "This is a normal string\
    ... with an escaped newline."
    'This is a normal stringwith an escaped newline.'

    >>> r"This is a raw string\
    ... with an escaped newline."
    'This is a raw string\\\nwith an escaped newline.'

This is not an issue with TQS's because they can naturally (i.e.
without escapes) span multiple lines.


Since your main objections above are much the same as Guido's, I'll
respond to his in this message also:

On 7/11/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
>
> The scheme may be explicitly spelled out in the language reference,
> but it is implicit to the human reader -- what you see is no longer
> what you get.

See discussion of explicitness vs. implicitness above.

> I recommend that you give it up. You ain't gonna convince me.

Very likely. But given the number of times that similar proposals have
been put forth in the past, it is reasonable to expect that they will
be brought up again in the future by others, if this is rejected--and
in that case, these other can simply be pointed to a thorough (but
rejected) PEP that discusses the proposal and variants and reasons for
rejection.

And so--while I still hope that you can be convinced (there's
precedent ;-), I think a good, thorough PEP will be of benefit even if
rejected. And, of course, such a PEP is bound to be more convincing
than a hasty ill-considered one. So I am rewriting my previous draft
accordingly, and will submit it as a PEP when it's done.

Cheers,

Andrew.

From jcarlson at uci.edu  Mon Jul 11 06:39:04 2005
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sun, 10 Jul 2005 21:39:04 -0700
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <59e9fd3a050710202721851037@mail.gmail.com>
References: <20050710084923.713E.JCARLSON@uci.edu>
	<59e9fd3a050710202721851037@mail.gmail.com>
Message-ID: <20050710211300.7144.JCARLSON@uci.edu>


Andrew Durdin <adurdin at gmail.com> wrote:
> 
> On 7/11/05, Josiah Carlson <jcarlson at uci.edu> wrote:
> >
> > You are wrong.  Current string literals are explicit.  They are what you
> > type.
> 
> No they are not:

Apparently my disclaimer of "except in the case of the decades-old
string escapes that were inherited from C, as well as unicode and 'raw'
strings" didn't make it into the final draft of that email.

It is not as though you are taking something that used to be invalid and
making it valid, you are taking something that used to mean X and making
it mean Y.  Your proposed change /will/ cause incompatibility for some
unknown number of modules which rely on the indentation of triple quoted
strings. You should realize that people get angry when their APIs change
the meaning of f(x), and you are asking for the language to do that.
Have you a guess as to why you are getting resistance?


 - Josiah


From bob at redivi.com  Mon Jul 11 07:08:16 2005
From: bob at redivi.com (Bob Ippolito)
Date: Sun, 10 Jul 2005 19:08:16 -1000
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <20050710211300.7144.JCARLSON@uci.edu>
References: <20050710084923.713E.JCARLSON@uci.edu>
	<59e9fd3a050710202721851037@mail.gmail.com>
	<20050710211300.7144.JCARLSON@uci.edu>
Message-ID: <15C52F0E-F1E2-4BA3-B49B-8F49CD4CCABF@redivi.com>


On Jul 10, 2005, at 6:39 PM, Josiah Carlson wrote:

>
> Andrew Durdin <adurdin at gmail.com> wrote:
>
>>
>> On 7/11/05, Josiah Carlson <jcarlson at uci.edu> wrote:
>>
>>>
>>> You are wrong.  Current string literals are explicit.  They are  
>>> what you
>>> type.
>>>
>>
>> No they are not:
>>
>
> Apparently my disclaimer of "except in the case of the decades-old
> string escapes that were inherited from C, as well as unicode and  
> 'raw'
> strings" didn't make it into the final draft of that email.
>
> It is not as though you are taking something that used to be  
> invalid and
> making it valid, you are taking something that used to mean X and  
> making
> it mean Y.  Your proposed change /will/ cause incompatibility for some
> unknown number of modules which rely on the indentation of triple  
> quoted
> strings. You should realize that people get angry when their APIs  
> change
> the meaning of f(x), and you are asking for the language to do that.
> Have you a guess as to why you are getting resistance?

A better proposal would probably be another string prefix that means  
"dedent", but I'm still not sold.  doc processing software is clearly  
going to have to know how to dedent anyway in order to support  
existing code.

-bob


From tjreedy at udel.edu  Mon Jul 11 07:33:23 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 11 Jul 2005 01:33:23 -0400
Subject: [Python-Dev] Triple-quoted strings and indentation
References: <ca471dc2050706081361f64dfc@mail.gmail.com><59e9fd3a05071004277905fbf9@mail.gmail.com><20050710084923.713E.JCARLSON@uci.edu>
	<59e9fd3a050710202721851037@mail.gmail.com>
Message-ID: <dat0b4$lt4$1@sea.gmane.org>


"Andrew Durdin" <adurdin at gmail.com> wrote in message 
news:59e9fd3a050710202721851037 at mail.gmail.com...
> Very likely. But given the number of times that similar proposals have
> been put forth in the past, it is reasonable to expect that they will
> be brought up again in the future by others, if this is rejected--and
> in that case, these other can simply be pointed to a thorough (but
> rejected) PEP that discusses the proposal and variants and reasons for
> rejection.

I agree that this would be useful.  I also agree with Bob Ippolito that a 
new prefex might be better.

tjr




From reinhold-birkenfeld-nospam at wolke7.net  Mon Jul 11 07:59:15 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Mon, 11 Jul 2005 07:59:15 +0200
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <dat0b4$lt4$1@sea.gmane.org>
References: <ca471dc2050706081361f64dfc@mail.gmail.com><59e9fd3a05071004277905fbf9@mail.gmail.com><20050710084923.713E.JCARLSON@uci.edu>	<59e9fd3a050710202721851037@mail.gmail.com>
	<dat0b4$lt4$1@sea.gmane.org>
Message-ID: <dat1rj$nl0$1@sea.gmane.org>

Terry Reedy wrote:
> "Andrew Durdin" <adurdin at gmail.com> wrote in message 
> news:59e9fd3a050710202721851037 at mail.gmail.com...
>> Very likely. But given the number of times that similar proposals have
>> been put forth in the past, it is reasonable to expect that they will
>> be brought up again in the future by others, if this is rejected--and
>> in that case, these other can simply be pointed to a thorough (but
>> rejected) PEP that discusses the proposal and variants and reasons for
>> rejection.
> 
> I agree that this would be useful.  I also agree with Bob Ippolito that a 
> new prefex might be better.

<plug>

Why using a new syntax construct when you can do it with existing features?

We do already have str.split(), which is often used to postprocess string
literals (in the perl qw() style), why not introduce str.dedent()?

Reinhold

-- 
Mail address is perfectly valid!


From martin at v.loewis.de  Mon Jul 11 08:36:17 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 11 Jul 2005 08:36:17 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <uwtny8eb8.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CD3052.6000704@acm.org>	<uy88ivgg0.fsf@boost-consulting.com>	<17101.16300.736797.378762@montanaro.dyndns.org>	<ud5putpjj.fsf@boost-consulting.com>	<17101.37403.452222.396424@montanaro.dyndns.org>	<upstup7r9.fsf@boost-consulting.com>
	<42CEFE31.1000800@v.loewis.de>	<uy88gg399.fsf@boost-consulting.com>
	<42D0CD7F.3080007@v.loewis.de>	<ueka6dc11.fsf@boost-consulting.com>
	<42D18E9D.8040701@v.loewis.de> <uwtny8eb8.fsf@boost-consulting.com>
Message-ID: <42D21361.9040708@v.loewis.de>

David Abrahams wrote:
>>- ccpython.cc and linking with g++ is removed entirely. or,
> 
> 
> That would be bad for C++ users on HP/UX.  Is that acceptable?

I hadn't read that far in the threads when I wrote this - I
guess the answer is no, and we must continue to support ccpython.cc.

>>- the logic is fixed so that linking with g++ is only done if
>>  main is in ccpython.o
> 
> 
> I don't see how that works.  Somehow we need to decide whether to put
> main in ccpython.o in the first place, don't we?

Yes, that is done through --with-cxx (alone). However, the decision
to use CXX for linking is independent on whether --with-cxx was
given.

>>- the configure test is extended to better match current g++
>>  behaviour.
> 
> 
> What do you have in mind?

Somebody reported that the test works better for g++ if the
function is marked extern "C". This should be done for 2.4
regardless of any other change.

>>I just checked, and it seems that the logic in use is still somewhat
>>different. If the configure test determines that a C++ main()
>>must be linked with CXX, it unconditionally changes the linker to CXX.
>>The test, in turn, is run always if a C++ compiler was found,
>>i.e. independently of whether --with-cxx was provided.
> 
> 
> That doesn't match up with reports from my testers who say they can
> run with C++ extension modules from many different GCC versions if
> they just configure their Python --without-cxx.  If what you were
> saying were true, wouldn't --without-cxx be ignored on ELF/Linux?

Ok, it's still different. I see three cases now:
1. --without-cxx or --with-cxx=no specified. configure does not look
   for a C++ compiler, and does not check whether linking needs
   to be done with a C++ compiler, and decides to use Modules/python.c.
2. --with-cxx not given. configure does look for a C++ compiler,
   and does check whether linking with the C++ compiler is necessary,
   and still uses Modules/python.c
3. --with-cxx is given. configure requires it to point to a C++
   compiler, performs the linking check, and uses Modules/ccpython.cc.

It would help discussion if you would use the actual code, too,
instead of just using reports from your testers.

Regards,
Martin


From mal at egenix.com  Mon Jul 11 09:14:11 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 11 Jul 2005 09:14:11 +0200
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <15C52F0E-F1E2-4BA3-B49B-8F49CD4CCABF@redivi.com>
References: <20050710084923.713E.JCARLSON@uci.edu>	<59e9fd3a050710202721851037@mail.gmail.com>	<20050710211300.7144.JCARLSON@uci.edu>
	<15C52F0E-F1E2-4BA3-B49B-8F49CD4CCABF@redivi.com>
Message-ID: <42D21C43.8040609@egenix.com>

Bob Ippolito wrote:
> A better proposal would probably be another string prefix that means  
> "dedent", but I'm still not sold.  doc processing software is clearly  
> going to have to know how to dedent anyway in order to support  
> existing code.

Agreed.

It is easy enough for any doc-string extraction tool
to do the dedenting based on the common whitespace prefix found
in lines 2 - n of the string. And that works on all sorts of string
literals.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 11 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From bjourne at gmail.com  Mon Jul 11 11:07:07 2005
From: bjourne at gmail.com (=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=)
Date: Mon, 11 Jul 2005 11:07:07 +0200
Subject: [Python-Dev] Chaining try statements: eltry?
In-Reply-To: <ca471dc205070710484a5894c4@mail.gmail.com>
References: <20050706200745.22493ade.thomas@thomas-lotze.de>
	<ca471dc2050706120231ecb092@mail.gmail.com>
	<20050707103833.327547ed.thomas@thomas-lotze.de>
	<ca471dc2050707063938b19fb2@mail.gmail.com>
	<20050707163452.GA12703@phenix.progiciels-bpi.ca>
	<ca471dc205070710484a5894c4@mail.gmail.com>
Message-ID: <740c3aec050711020774a894e0@mail.gmail.com>

> > I surely find them useful, and see them as a Python originality (a
> > welcome one).
> 
> They are indeed an original invention. (One day I looked at the
> similarity between if and while and noticed that there was a use case
> for else after while too.)
> 
> The question remains whether Python would be easier to learn without
> them. And if so, the question would remain whether that's offset by
> their utility for experienced developers. All hard to assess
> impartially!

I dislike them because I can never read looping constructs with else:
without thinking hard about what it does. Like:

for x in alist:
    if x == "foo":
        break
else:
    print "foo was not found."

Is a better way of doing:

found = False
for x in alist:
    if x == "foo":
        found = True
        break
if not found:
    print "foo was not found."

So the else: is taken if the break wasn't executed. I think that is
hard to grasp because it makes the for and break into a kind of
conditional statement where break makes it evalute to true. But I
think the best way to code this silly example is to write:

def finder():
    for x in alist:
        if x == "foo":
            return True
    return False
if not finder():
    print "foo was not found."

Which is how I write when someone else might had used a "else." So
IMHO, the use cases are weak. It's also confusing that try: has a
different kind of else. "else" in "try" is a good thing - no exception
occured. "else" in a for/while is (usually) a bad thing - as item was
not found.

-- 
mvh Bj?rn

From ncoghlan at gmail.com  Mon Jul 11 11:07:46 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 11 Jul 2005 19:07:46 +1000
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <dar44m$86h$1@sea.gmane.org>
References: <59e9fd3a0507052116307e4d84@mail.gmail.com>	<ca471dc2050706081361f64dfc@mail.gmail.com>
	<dar44m$86h$1@sea.gmane.org>
Message-ID: <42D236E2.7030808@gmail.com>

Reinhold Birkenfeld wrote:
> Guido van Rossum wrote:
> 
>>On 7/5/05, Andrew Durdin <adurdin at gmail.com> wrote:
>>
>>>I have written a patch that changes the way triple-quoted strings are
>>>scanned so that leading whitespace is ignored in much the same way
>>>that pep 257 handles it for docstrings. Largely this was for a
>>>learning experience in hacking the parser, but it would be very nice
>>>IMO if something of this sort could be implemented in a future version
>>>of Python.
>>
>>I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI.
> 
> 
> Another idea, which is much more conservative: textwrap.dedent is highly under-
> rated and hidden. Why not make it builtin or a string method?
> 
> Reinhold
> 

Using Andrew's examples from the PEP:

         def usage(outfile):
             outfile.write(
              """Usage: %s [OPTIONS] <file> [ARGS]

                 Meta-options:
                 --help                Display this help then exit.
                 --version             Output version information then exit.
                 """.dedent() % sys.argv[0])

         self.runcommand("""\
             if 1:
                 import sys as _sys
                 _sys.path = %r
                 del _sys
                 \n""".dedent() % (sys.path,))

         class WrapTestCase(BaseTestCase):
             def test_subsequent_indent(self):
                 # Test subsequent_indent parameter
                  expect = '''\
                       * This paragraph will be filled, first
                         without any indentation, and then
                         with some (including a hanging
                         indent).
                     '''.dedent().rstrip()
                 result = fill(self.text, 40,
                               initial_indent="  * ",
                               subsequent_indent="    ")
                 self.check(result, expect)

And if the loading of the textwrap module is deferred to the first call to 
dedent(), then it wouldn't even need to incur any extra start up overhead.

Although that last example is a bad one, since you end up testing textwrap 
against itself ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From mwh at python.net  Mon Jul 11 11:32:48 2005
From: mwh at python.net (Michael Hudson)
Date: Mon, 11 Jul 2005 10:32:48 +0100
Subject: [Python-Dev] C bindings calling tmpfile() blocks interrupt
 signal
In-Reply-To: <d143d3ff05071002292f49cac7@mail.gmail.com> (Florent Pillet's
	message of "Sun, 10 Jul 2005 11:29:08 +0200")
References: <d143d3ff0507070517154ec286@mail.gmail.com>
	<2mhdf6vkls.fsf@starship.python.net>
	<d143d3ff05071002292f49cac7@mail.gmail.com>
Message-ID: <2mzmstu1q7.fsf@starship.python.net>

Florent Pillet <fpillet at gmail.com> writes:

> On 07/07/05, Michael Hudson <mwh at python.net> wrote:
>>>
>> > But with my threaded Python code, SIGINT doesn't work anymore after my
>> > binding has called tmpfile().
>> 
>> Oh, threads.
>> 
>> Which version of Python are you using?
>
> 2.3.5, the one that ships with Mac OS X 10.4. I have a 2.4.x install
> somewhere, I'll give it a go. 

Please do.  If my guess as to what's going on is right, you won't have
the problem.

> But you're right, it's probably because of threads.

You *may* be able to work around this by only calling tmpfile on the
main thread (just a guess).

> Now I'm trying to determine whether this is a Python bug or a Mac OS
> X bug...

Well, again assuming my guess is right, it's probably an OS X bug, but
really threads vs signals issues are enormously subtle and frequently
messed up.

Python 2.4 is much less vulnerable to such cock ups.

Cheers,
mwh

-- 
  we're already scrubbing the face of intuition with steel wool,
  setting it on fire, then putting it out with an axe <wink>.
                      -- Tim Peters, on comparing recursive structures

From anthony at interlink.com.au  Mon Jul 11 11:51:12 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Mon, 11 Jul 2005 19:51:12 +1000
Subject: [Python-Dev] C bindings calling tmpfile() blocks interrupt
	signal
In-Reply-To: <2mzmstu1q7.fsf@starship.python.net>
References: <d143d3ff0507070517154ec286@mail.gmail.com>
	<d143d3ff05071002292f49cac7@mail.gmail.com>
	<2mzmstu1q7.fsf@starship.python.net>
Message-ID: <200507111951.15380.anthony@interlink.com.au>

On Monday 11 July 2005 19:32, Michael Hudson wrote:
> Well, again assuming my guess is right, it's probably an OS X bug, but
> really threads vs signals issues are enormously subtle and frequently
> messed up.

I think mwh meant to say "threads vs signals is a platform-dependant 
trail of misery, despair, horror and madness". 

> Python 2.4 is much less vulnerable to such cock ups.

Note that the underlying platform issues are still there, it's
just that Python itself is much less likely to lose on these 
issues. This is also probably only true for mainstream operating
systems - for the more niche ones like HP/UX or Irix, there's 
quite probably still issues hanging around. These are unlikely to
get fixed unless someone who cares about these platforms is willing
to spend a lot of time working on it. At one point, I was spending
some time on this (using the DEC^WCompaq^WHP "testdrive" systems), 
but I stopped caring about them quite a while ago now. Too much
pain, for zero gain for me. 


-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

From mwh at python.net  Mon Jul 11 12:19:47 2005
From: mwh at python.net (Michael Hudson)
Date: Mon, 11 Jul 2005 11:19:47 +0100
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <17102.64600.669006.871379@montanaro.dyndns.org> (Skip
	Montanaro's message of "Fri, 8 Jul 2005 17:21:12 -0500")
References: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>
	<17102.64600.669006.871379@montanaro.dyndns.org>
Message-ID: <2mvf3htzjw.fsf@starship.python.net>

Skip Montanaro <skip at pobox.com> writes:

> Ummm...  What's a "context manager"?

Something that goes 

with ... as var:
     ^ here

If you have a better name, feel free to suggest it, but please catch
up on python-dev first (it's been discussed to unconsciousness, if not
quite death, in the last week or so).

Cheers,
mwh

-- 
  <dash> i am trying to get Asterisk to work
  <dash> it is stabbing me in the face
  <dreid> yes ... i seem to recall that feature in the documentation
                                                -- from Twisted.Quotes

From mwh at python.net  Mon Jul 11 12:26:04 2005
From: mwh at python.net (Michael Hudson)
Date: Mon, 11 Jul 2005 11:26:04 +0100
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42D0CD7F.3080007@v.loewis.de> (
	=?iso-8859-1?q?Martin_v._L=F6wis's_message_of?= "Sun,
	10 Jul 2005 09:25:51 +0200")
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
Message-ID: <2mr7e5tz9f.fsf@starship.python.net>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> However, you will find that with a), people will still pass --with-cxx,
> because they tend to "enable" all features they can find.

--with-fpectl, for example.  Does anyone lurking here actually use
that, know what it does and require the functionality?  Inquiring
minds want to know.

Cheers,
mwh

-- 
  I think perhaps we should have electoral collages and construct
  our representatives entirely of little bits of cloth and papier 
  mache.          -- Owen Dunn, ucam.chat, from his review of the year

From barry at python.org  Mon Jul 11 13:50:55 2005
From: barry at python.org (Barry Warsaw)
Date: Mon, 11 Jul 2005 07:50:55 -0400
Subject: [Python-Dev] Triple-quoted strings and indentation
In-Reply-To: <15C52F0E-F1E2-4BA3-B49B-8F49CD4CCABF@redivi.com>
References: <20050710084923.713E.JCARLSON@uci.edu>
	<59e9fd3a050710202721851037@mail.gmail.com>
	<20050710211300.7144.JCARLSON@uci.edu>
	<15C52F0E-F1E2-4BA3-B49B-8F49CD4CCABF@redivi.com>
Message-ID: <1121082655.11051.130.camel@presto.wooz.org>

On Mon, 2005-07-11 at 01:08, Bob Ippolito wrote:

> A better proposal would probably be another string prefix that means  
> "dedent", but I'm still not sold.  doc processing software is clearly  
> going to have to know how to dedent anyway in order to support  
> existing code.

OTOH, adding another string prefix means doubling the total number of
prefix combinations.  The potential for this getting out of hand was the
primary reason that string templates were implemented as a library
function instead of as a string prefix.

Personally, I'm not convinced that string literals need to change in any
way.  Dedentation should be handled (is handled?!) in the stdlib.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050711/21dd12e7/attachment.pgp

From dave at boost-consulting.com  Mon Jul 11 14:37:04 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 11 Jul 2005 08:37:04 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42D21361.9040708@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Mon, 11 Jul 2005 08:36:17 +0200")
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
	<ueka6dc11.fsf@boost-consulting.com> <42D18E9D.8040701@v.loewis.de>
	<uwtny8eb8.fsf@boost-consulting.com> <42D21361.9040708@v.loewis.de>
Message-ID: <uk6jx8qof.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

>>>- the logic is fixed so that linking with g++ is only done if
>>>  main is in ccpython.o
>> 
>> 
>> I don't see how that works.  Somehow we need to decide whether to put
>> main in ccpython.o in the first place, don't we?
>
> Yes, that is done through --with-cxx (alone). However, the decision
> to use CXX for linking is independent on whether --with-cxx was
> given.

Is the above a description of existing behavior or a behavior you're
proposing?

>
>>>- the configure test is extended to better match current g++
>>>  behaviour.
>> 
>> 
>> What do you have in mind?
>
> Somebody reported that the test works better for g++ if the
> function is marked extern "C". 

Which function?
What does "works better" mean?

> This should be done for 2.4 regardless of any other change.
>
>>>I just checked, and it seems that the logic in use is still somewhat
>>>different. If the configure test determines that a C++ main()
>>>must be linked with CXX, it unconditionally changes the linker to CXX.
>>>The test, in turn, is run always if a C++ compiler was found,
>>>i.e. independently of whether --with-cxx was provided.
>> 
>> 
>> That doesn't match up with reports from my testers who say they can
>> run with C++ extension modules from many different GCC versions if
>> they just configure their Python --without-cxx.  If what you were
>> saying were true, wouldn't --without-cxx be ignored on ELF/Linux?
>
> Ok, it's still different. I see three cases now:
> 1. --without-cxx or --with-cxx=no specified. configure does not look
>    for a C++ compiler, and does not check whether linking needs
>    to be done with a C++ compiler, and decides to use Modules/python.c.
> 2. --with-cxx not given. configure does look for a C++ compiler,
>    and does check whether linking with the C++ compiler is necessary,
>    and still uses Modules/python.c
> 3. --with-cxx is given. configure requires it to point to a C++
>    compiler, performs the linking check, and uses Modules/ccpython.cc.

Is the above a description of existing behavior or is it a behavior
you're proposing?

> It would help discussion if you would use the actual code, too,
> instead of just using reports from your testers.

I don't know what you mean by "use the actual code."  Do you mean,
refer to the actual code in the discussion, or do you mean actually
building and running Python --without-cxx myself?  If the latter, I
don't see a reason to repeat what people I trust have already done.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From nyamatongwe at gmail.com  Mon Jul 11 15:55:34 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Mon, 11 Jul 2005 23:55:34 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <ca471dc205070911216a57ff6e@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<50862ebd05070604117e9c5fb4@mail.gmail.com> <y88j3pqo.fsf@python.net>
	<50862ebd05070805431808b7e5@mail.gmail.com> <wto1wdzv.fsf@python.net>
	<50862ebd05070820506a829c45@mail.gmail.com>
	<42CFAFBD.2010202@egenix.com>
	<50862ebd0507090604290df5f6@mail.gmail.com>
	<ca471dc205070911216a57ff6e@mail.gmail.com>
Message-ID: <50862ebd05071106553fba99cb@mail.gmail.com>

Guido van Rossum:

> In some sense the safest approach from this POV would be to return
> Unicode as soon as it can't be encoded using the global default
> encoding. IOW normally this would return Unicode for all names
> containing non-ASCII characters.

   On unicode versions of Windows, for attributes like os.listdir,
os.getcwd, sys.argv, and os.environ, which can usefully return unicode
strings, there are 4 options I see:

1) Always return unicode. This is the option I'd be happiest to use,
myself, but expect this choice would change the behaviour of existing
code too much and so produce much unhappiness.

2) Return unicode when the text can not be represented in ASCII. This
will cause a change of behaviour for existing code which deals with
non-ASCII data.

3) Return unicode when the text can not be represented in the default
code page. While this change can lead to breakage because of combining
byte string and unicode strings, it is reasonably safe from the point
of view of data integrity as current code is returning garbage strings
that look like '?????'.

4) Provide two versions of the attribute, one with the current name
returning byte strings and a second with a "u" suffix returning
unicode. This is the least intrusive, requiring explicit changes to
code to receive unicode data. For patch #1231336 I chose this approach
producing sys.argvu and os.environu.

    For os.listdir the current behaviour of returning unicode when its
argument is unicode can be retained but that is not extensible to, for
example, sys.argv.

   Since this issue may affect many attributes a common approach
should be chosen.

   For experimenting with os.listdir, there is a patch for
posixmodule.c at http://www.scintilla.org/difft.txt which implements
(2). To specify the US-ASCII code page, the number 20127 is used as
there is no definition for this in the system headers. To change to
(3) comment out the line with 20127 and uncomment the line with
CP_ACP. Unicode arguments produce unicode results.

   Neil

From nyamatongwe at gmail.com  Mon Jul 11 15:55:40 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Mon, 11 Jul 2005 23:55:40 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <42D00CDA.9000300@egenix.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<50862ebd05070604117e9c5fb4@mail.gmail.com> <y88j3pqo.fsf@python.net>
	<50862ebd05070805431808b7e5@mail.gmail.com> <wto1wdzv.fsf@python.net>
	<50862ebd05070820506a829c45@mail.gmail.com>
	<42CFAFBD.2010202@egenix.com>
	<50862ebd0507090604290df5f6@mail.gmail.com>
	<42D00CDA.9000300@egenix.com>
Message-ID: <50862ebd05071106554017d4d9@mail.gmail.com>

M.-A. Lemburg:

> It's naive to assume that all people in Germany using the German
> locale have German names ;-) 

   That is not an assumption I would make. The assumption I would make
is that if it is important to you to have your account name in a
particular character set then you will normally set your locale to
enable easy use of that account.

> I'm not sure why you bring up an administration tool: isn't
> the discussion about being able to load Python modules from
> directories with Unicode path components ?

   The discussion has moved between various aspects of unicode support
in Python. There are many areas of the Python library which are not
compatible with unicode and having an idea of the incidence of
particular situations helps define where effort is most effectively
spent. My experience has been that because of the way Windows handles
character set conversions, problems are less common on individual's
machines than they are on servers.

   Neil

From skip at pobox.com  Mon Jul 11 16:01:08 2005
From: skip at pobox.com (Skip Montanaro)
Date: Mon, 11 Jul 2005 09:01:08 -0500
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <2mvf3htzjw.fsf@starship.python.net>
References: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>
	<17102.64600.669006.871379@montanaro.dyndns.org>
	<2mvf3htzjw.fsf@starship.python.net>
Message-ID: <17106.31652.667441.511084@montanaro.dyndns.org>


    >> Ummm...  What's a "context manager"?

    Michael> Something that goes 

    Michael> with ... as var:
    Michael>      ^ here

    Michael> If you have a better name, feel free to suggest it, but please
    Michael> catch up on python-dev first (it's been discussed to
    Michael> unconsciousness, if not quite death, in the last week or so).

After seeing so many messages about "with" statements my eyes began to glaze
over, so I stopped following that thread.  Then I saw mention of "context
manager" with no reference to any PEPs or to the with statement to provide
context.  None of the context-providing messages seemed to have been indexed
by Google when I checked, so searching for "Python context manager" failed
to return anything useful.  Hence the post.

BTW, "context manager" seems fine to me in that context...

Skip

From mal at egenix.com  Mon Jul 11 16:29:22 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 11 Jul 2005 16:29:22 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE
	for	review)
In-Reply-To: <50862ebd05071106553fba99cb@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>	
	<ca471dc205070400441ab49ffb@mail.gmail.com>	
	<50862ebd05070604117e9c5fb4@mail.gmail.com>
	<y88j3pqo.fsf@python.net>	
	<50862ebd05070805431808b7e5@mail.gmail.com>
	<wto1wdzv.fsf@python.net>	
	<50862ebd05070820506a829c45@mail.gmail.com>	
	<42CFAFBD.2010202@egenix.com>	
	<50862ebd0507090604290df5f6@mail.gmail.com>	
	<ca471dc205070911216a57ff6e@mail.gmail.com>
	<50862ebd05071106553fba99cb@mail.gmail.com>
Message-ID: <42D28242.4060306@egenix.com>

Neil Hodgson wrote:
>    On unicode versions of Windows, for attributes like os.listdir,
> os.getcwd, sys.argv, and os.environ, which can usefully return unicode
> strings, there are 4 options I see:
> 
> 1) Always return unicode. This is the option I'd be happiest to use,
> myself, but expect this choice would change the behaviour of existing
> code too much and so produce much unhappiness.

Would be nice, but will likely break too much code - if you
let Unicode object enter non-Unicode aware code, it is likely
that you'll end up getting stuck in tons of UnicodeErrors. If you
want to get a feeling for this, try running Python with -U command
line switch.

> 2) Return unicode when the text can not be represented in ASCII. This
> will cause a change of behaviour for existing code which deals with
> non-ASCII data.

+1 on this one (s/ASCII/Python's default encoding).

> 3) Return unicode when the text can not be represented in the default
> code page. While this change can lead to breakage because of combining
> byte string and unicode strings, it is reasonably safe from the point
> of view of data integrity as current code is returning garbage strings
> that look like '?????'.

-1: code pages are evil and the reason why Unicode was invented
in the first place. This would be a step back in history.

> 4) Provide two versions of the attribute, one with the current name
> returning byte strings and a second with a "u" suffix returning
> unicode. This is the least intrusive, requiring explicit changes to
> code to receive unicode data. For patch #1231336 I chose this approach
> producing sys.argvu and os.environu.

-1 - this is what Microsoft did for many of their APIs. The
result is two parallel universes with two sets of features,
bugs, documentation, etc.

>     For os.listdir the current behaviour of returning unicode when its
> argument is unicode can be retained but that is not extensible to, for
> example, sys.argv.

I don't think that using the parameter type as "parameter"
to function is a good idea. However, accepting both strings
and Unicode will make it easier to maintain backwards
compatibility.

>    Since this issue may affect many attributes a common approach
> should be chosen.

Indeed.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 11 2005)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From gvanrossum at gmail.com  Mon Jul 11 18:06:18 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Mon, 11 Jul 2005 09:06:18 -0700
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <42D28242.4060306@egenix.com>
References: <d9mmd6$gjf$1@sea.gmane.org> <y88j3pqo.fsf@python.net>
	<50862ebd05070805431808b7e5@mail.gmail.com> <wto1wdzv.fsf@python.net>
	<50862ebd05070820506a829c45@mail.gmail.com>
	<42CFAFBD.2010202@egenix.com>
	<50862ebd0507090604290df5f6@mail.gmail.com>
	<ca471dc205070911216a57ff6e@mail.gmail.com>
	<50862ebd05071106553fba99cb@mail.gmail.com>
	<42D28242.4060306@egenix.com>
Message-ID: <ca471dc2050711090652cf92fc@mail.gmail.com>

I'm in full agreement with Marc-Andre below, except I don't like (1)
at all -- having used other APIs that always return Unicode (like the
Python XML parsers) it bothers me to get Unicode for no reason at all.
OTOH I think Python 3.0 should be using a Unicode model closer to
Java's.

On 7/11/05, M.-A. Lemburg <mal at egenix.com> wrote:
> Neil Hodgson wrote:
> >    On unicode versions of Windows, for attributes like os.listdir,
> > os.getcwd, sys.argv, and os.environ, which can usefully return unicode
> > strings, there are 4 options I see:
> >
> > 1) Always return unicode. This is the option I'd be happiest to use,
> > myself, but expect this choice would change the behaviour of existing
> > code too much and so produce much unhappiness.
> 
> Would be nice, but will likely break too much code - if you
> let Unicode object enter non-Unicode aware code, it is likely
> that you'll end up getting stuck in tons of UnicodeErrors. If you
> want to get a feeling for this, try running Python with -U command
> line switch.
> 
> > 2) Return unicode when the text can not be represented in ASCII. This
> > will cause a change of behaviour for existing code which deals with
> > non-ASCII data.
> 
> +1 on this one (s/ASCII/Python's default encoding).
> 
> > 3) Return unicode when the text can not be represented in the default
> > code page. While this change can lead to breakage because of combining
> > byte string and unicode strings, it is reasonably safe from the point
> > of view of data integrity as current code is returning garbage strings
> > that look like '?????'.
> 
> -1: code pages are evil and the reason why Unicode was invented
> in the first place. This would be a step back in history.
> 
> > 4) Provide two versions of the attribute, one with the current name
> > returning byte strings and a second with a "u" suffix returning
> > unicode. This is the least intrusive, requiring explicit changes to
> > code to receive unicode data. For patch #1231336 I chose this approach
> > producing sys.argvu and os.environu.
> 
> -1 - this is what Microsoft did for many of their APIs. The
> result is two parallel universes with two sets of features,
> bugs, documentation, etc.
> 
> >     For os.listdir the current behaviour of returning unicode when its
> > argument is unicode can be retained but that is not extensible to, for
> > example, sys.argv.
> 
> I don't think that using the parameter type as "parameter"
> to function is a good idea. However, accepting both strings
> and Unicode will make it easier to maintain backwards
> compatibility.
> 
> >    Since this issue may affect many attributes a common approach
> > should be chosen.
> 
> Indeed.
> 
> --
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Source  (#1, Jul 11 2005)
>  >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>  >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>  >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
> 
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
> 


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

From gvanrossum at gmail.com  Mon Jul 11 19:46:36 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Mon, 11 Jul 2005 10:46:36 -0700
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <5DFC492F-2A4D-4926-926D-6F74B48FA516@fuhm.net>
References: <damndu$3fk$1@sea.gmane.org>
	<bbaeab100507081346e0676dd@mail.gmail.com>
	<5DFC492F-2A4D-4926-926D-6F74B48FA516@fuhm.net>
Message-ID: <ca471dc2050711104664bba54e@mail.gmail.com>

On 7/8/05, James Y Knight <foom at fuhm.net> wrote:
> It is a really bad idea to codify the practice of modifying non-
> threadlocal global state like sys.std[in|out|err] and current
> directory with a context manager. A user can do it to themselves now,
> true, but by putting a context manager for it in the stdlib, you make
> it look like it'd be a local modification when it is not. I can only
> see confusion resulting from this. Users will inevitably try to use
> it like
>    with sys.redirected_stderr(f):

Which is of course a bug -- print doesn't go to stderr. Not sure if
you meant this as an illustration of a typical bug or whether you
meant sys.redirect_stdout(f).

>      print "hello"
>      print "there"
> instead of explicitly writing to f with print>> or write(). And that
> is just a terribly bad idea. It looks pretty, yes, but unless
> stdinouterr are made thread-local, it's just asking for trouble.

Boy, do you have Java (or multi-threading) on your mind. A lot of
Python programs are single-threaded, and this idiom has been promoted
by examples for many years; I see nothing wrong with it in
single-threaded code. I sure hope the world doesn't evolve to one
where most programs have to be multi-threaded to be useful!
Multi-threading is such a nightmare to program that we should really
look for paradigms that hide it completely rather than trying to raise
programmers who will write correct multi-threaded programs naturally;
the latter just ain't gonna happen.

A major use case for this, BTW, is to take *existing* Python code that
was written using print statements and wrap it in something that
captures its output. The f.write() or print>>f solutions won't work
there...

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

From mcherm at mcherm.com  Mon Jul 11 20:19:14 2005
From: mcherm at mcherm.com (Michael Chermside)
Date: Mon, 11 Jul 2005 11:19:14 -0700
Subject: [Python-Dev] Possible context managers in stdlib
Message-ID: <20050711111914.czz28zgrrsowcw4k@login.werra.lunarpages.com>

I wrote:
> I agree with Barry. Not only should they be in the stdlib, but they
> should have very clear warnings in their docstrings and other documentation
> that state that they are ONLY safe to use in single-threaded programs.
>
> This achieves two things: it makes them available to those who need
> them (not everyone uses threads!), and it rather forcefully makes the
> point that it's NOT usually a good idea to modify global state info in
> a context manager because doing so is not generally threadsafe.

Nick Coghlan replies:
> Wouldn't they be able to actually emit a warning at run-time if they're used
> in a multi-threaded program? That would be even better motivation for
> including them, IMO.

I don't think that would be desirable. These things CAN be useful in a
multi-threaded program if you know what you're doing. One common example
would be to use them only from the main thread.

-- Michael Chermside


From cludwig at cdc.informatik.tu-darmstadt.de  Sun Jul 10 14:54:59 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sun, 10 Jul 2005 14:54:59 +0200
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
In-Reply-To: <42D0D215.9000708@v.loewis.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
Message-ID: <20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>

On Sun, Jul 10, 2005 at 09:45:25AM +0200, "Martin v. L?wis" wrote:
> Christoph Ludwig wrote:
> >>I'll describe it once more: *If* a program is compiled with the C++
> >>compiler, is it *then* possible to still link it with the C compiler?
> >>This is the question this test tries to answer.
> > 
> > 
> > The keyword here is "tries"
> 
> Any such test would only "try": to really determine whether this is
> necessary for all possible programs, one would have to test all possible
> programs. Since there is an infinite number of programs, this test could
> take a while.

Sure. You cannot write a test that gives the correct result for all platforms
you can think of, covering every compiler / linker quirk. I never claimed that
is possible.

My point is: The test implemented in the 2.4.1 configure script gives a wrong
result if your platform happens to be x86 Linux with ELF binaries and 
g++ 4.0. 

> The original test, on the original system, would cause __main to be
> undefined, and then decide to use C++. For a long time, on systems
> that don't use collect2, the test *correctly* determined that linking
> with g++ was not necessary.
> 
> It is only recent changes to g++ that break the test, namely the
> introduction of this __gxx_personality_v0 thing.

The test broke due to a change in GCC 4.0, but the "__gxx_personality_v0
thing" was introduced long before. It is merely a symptom. I ran the tests
with GCC 3.3.1, 3.4.2, and 4.0.0. Here are the results:

  GCC version       1 TU        2 TUs
    3.3.1            g++         g++
    3.4.2            g++         g++
    4.0.0            gcc         g++

(1 TU: test with one translation unit, as in Python 2.4.1.
 2 TUs: test with two translation units, as in my last posting.
 g++ / gcc: test indicates linking the executable requires g++ / gcc,
 respectively.)

With GCC 3.3.1 and 3.4.2, linking of the executable conftest in the 1 TU test
fails because of an unresolved symbol __gxx_personality_v0. Therefore, python
is linked with g++.

The change that makes GCC 4.0.0 break the 1 TU test is that the compiler
apparently does a better job eliminating unreachable code. In the 1 TU test,
it recognizes __gxx_personality_v0 (or the code that refers to this symbol) is
unreachable and removes it. It seems there are no other symbols left that
depend on libstdc++ so suddenly conftest can be linked with gcc.

> > - my bug report #1189330 exihibts that the test
> > fails to do its job. And looking at the test that's certainly no surprise:
> 
> However, it *is* a surprise that your modified test fixes the problem.
> 
> > Note that there is *no* reference to any symbol in another TU. The compiler
> > can detect that foo() won't throw any exceptions, that there is no need for RTTI
> > and whatever else the C++ runtime provides. Consequently, the object file
> > produced by g++ does not contain any reference to symbols in libstdc++.
> 
> You are assuming implementation details here. I have seen
> implementations of C++ (eg. g++ with collect2) where the test determines
> that linking with C++ is necessary (because __main was undefined), as
> well as systems where the test decides *correctly* that linking with
> C++ is not necessary (e.g. gcc 2.x on an ELF system). That some C++
> compiler introduces the C++ runtime if some C function may throw an
> exception is a very specific detail of this C++ compiler.

I am not aware of any rule that makes the following program ill-formed:

  // in a.cc:
  extern "C" void foo();

  int main() {
    foo();
  }

  // in b.cc
  extern "C" void foo() {
    throw 1;
  }

Provided the compiler does not do optimizations across translation units, it
has no way to determine in a.cc whether foo() is really a C function (i.e.,
compiled by a C compiler) or a C++ function with "C" linkage. I think a
conforming C++ compiler has to provide for the case that foo() might throw. It
was a very specific detail of gcc 2.x if it failed to do so. (A venial
omission, I admit.)


But I digress. It's not that important for our discussion whether a C++
compiler must / should / is allowed to add exception handling code to the
call of an extern "C" function. The point is that some do *unless* they see
the function definition. I contend the test involving two TUs matches more
closely the situation with ccpython.cc than the current test.

I do not claim the 2 TUs test will cover all possible scenarios. I am not even
sure this decision should be left to an automated test. Because if the test
breaks for some reason then the user is left with a linker error that is
time-consuming to track down.

> > Of course, if you insist on this "dependency optimization" then you can try to
> > fix Python's configure.in by using the second test above. But I would still
> > not trust it to cover all configurations on all platforms supported by
> > Python. 
> 
> Of couse not. This is just autoconf: it does not allow magical porting
> to all possible future operating systems. Instead, from time to time,
> explicit porting activity is necessary. This is not just about this
> specific detail, but about many other details. Each new operation
> system, library, or compiler version might break the build process.

Instead of having yet another test in configure.in that may break on a new
platform and that needs maintenance wouldn't it be better to assume that
--with-cxx implies linking with the C++ compiler and telling users how to
override this assumption? Would it cause so much inconvenience to users
provided the explanation of --with-cxx in the README would be modified?

I think of an explanation along the lines of:

--with-cxx=<compiler>: If you plan to use C++ extension modules, then on some
        platform you need to compile python's main() function with the C++
        compiler. With this option, make will use <compiler> to compile main()
        *and* to link the python executable. It is likely that the resulting
        executable depends on the C++ runtime library of <compiler>.

        Note there are platforms that do not require you to build Python with
        a C++ compiler in order to use C++ extension modules. E.g., x86 Linux
        with ELF shared binaries and GCC 3.x, 4.x is such a platform. We
        recommend that you configure Python --without-cxx on those platforms
        to avoid unnecessary dependencies.

        If you need to compile main() with <compiler>, but your platform does
        not require that you also link the python executable with <compiler> 
        (e.g., <example platform>), then set LINKCC='$(PURIFY) $(CC)' prior to
        calling make. Then the python executable will not depend on the C++
        runtime library of <compiler>.


BTW, I'd also change the short explanation output by `configure --help'.
Something like:

  AC_HELP_STRING(--with-cxx=<compiler>, 
                 use <compiler> to compile and link main())

In Python 2.4.1, the help message says "enable C++ support". That made me use
this option even though it turned out it is not necessary on my platform.

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html


From cludwig at cdc.informatik.tu-darmstadt.de  Sun Jul 10 16:49:47 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sun, 10 Jul 2005 16:49:47 +0200
Subject: [Python-Dev] [C++-sig]    GCC version compatibility
In-Reply-To: <u64vidbru.fsf@boost-consulting.com>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<u64vidbru.fsf@boost-consulting.com>
Message-ID: <20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>

On Sun, Jul 10, 2005 at 09:35:33AM -0400, David Abrahams wrote:
> Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:
> 
> > I do not claim the 2 TUs test will cover all possible scenarios. I am not even
> > sure this decision should be left to an automated test. Because if the test
> > breaks for some reason then the user is left with a linker error that is
> > time-consuming to track down.
> 
> However, at least by the usual hierarchy of values, the sort of
> runtime error that results from the current needless linking with C++
> on ELF/Linux is even worse.

Yes, but on ELF/Linux the default configuration should be --without-cxx
in the first place. If the build instructions make it sufficiently clear that
you should prefer this configuration whenever possible then this should be a
non-issue on platforms like ELF/Linux.

We learned that there are indeed platforms that require --with-cxx. There is
not much we can do for user on platforms that that also require the final
executable to be linked with the C++ compiler. They have to live with the
dependency on the C++ runtime and the likely runtime errors if the import
extension modules built with a different C++ compiler.

What about the platforms that require compilation of main() with a C++
compiler but allow you to link with the C compiler - can you import a C++
extension module built with C++ compiler version X if the main() function of
the Python interpreter was compiled with C++ compiler version Y, X != Y?
If not, then we are back to the runtime error, no matter whether there is a
dependency on the C++ runtime library or not.

So the automated test in configure could spare users runtime errors if they
must configure --with-cxx and if they can link with the C compiler and if the
C++ compiler versions used for building the Python interpreter and the
extension module do not need to coincide. I don't know how large the subset of
platforms is that satisfy these conditions.

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html


From martin at v.loewis.de  Tue Jul 12 00:30:17 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 12 Jul 2005 00:30:17 +0200
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <uk6jx8qof.fsf@boost-consulting.com>
References: <u64vmycwv.fsf@boost-consulting.com>
	<42CD3052.6000704@acm.org>	<uy88ivgg0.fsf@boost-consulting.com>	<17101.16300.736797.378762@montanaro.dyndns.org>	<ud5putpjj.fsf@boost-consulting.com>	<17101.37403.452222.396424@montanaro.dyndns.org>	<upstup7r9.fsf@boost-consulting.com>
	<42CEFE31.1000800@v.loewis.de>	<uy88gg399.fsf@boost-consulting.com>
	<42D0CD7F.3080007@v.loewis.de>	<ueka6dc11.fsf@boost-consulting.com>
	<42D18E9D.8040701@v.loewis.de>	<uwtny8eb8.fsf@boost-consulting.com>
	<42D21361.9040708@v.loewis.de> <uk6jx8qof.fsf@boost-consulting.com>
Message-ID: <42D2F2F9.4070106@v.loewis.de>

David Abrahams wrote:
>>>I don't see how that works.  Somehow we need to decide whether to put
>>>main in ccpython.o in the first place, don't we?
>>
>>Yes, that is done through --with-cxx (alone). However, the decision
>>to use CXX for linking is independent on whether --with-cxx was
>>given.
> 
> 
> Is the above a description of existing behavior or a behavior you're
> proposing?

This is the current behaviour. See the code to see for yourself.

>>Somebody reported that the test works better for g++ if the
>>function is marked extern "C". 
> 
> 
> Which function?

foo().

> What does "works better" mean?

It correctly detects that linking with g++ is necessary on the
specific system in question (see bug report #1205568)

>>Ok, it's still different. I see three cases now:
>>1. --without-cxx or --with-cxx=no specified. configure does not look
>>   for a C++ compiler, and does not check whether linking needs
>>   to be done with a C++ compiler, and decides to use Modules/python.c.
>>2. --with-cxx not given. configure does look for a C++ compiler,
>>   and does check whether linking with the C++ compiler is necessary,
>>   and still uses Modules/python.c
>>3. --with-cxx is given. configure requires it to point to a C++
>>   compiler, performs the linking check, and uses Modules/ccpython.cc.
> 
> 
> Is the above a description of existing behavior or is it a behavior
> you're proposing?

This is existing behaviour (or what I believe existing behaviour to
be).

> I don't know what you mean by "use the actual code."  Do you mean,
> refer to the actual code in the discussion, or do you mean actually
> building and running Python --without-cxx myself?  If the latter, I
> don't see a reason to repeat what people I trust have already done.

You wouldn't have to ask these questions if you had investigated the
answers yourself.

Regards,
Martin


From martin at v.loewis.de  Tue Jul 12 01:07:56 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 12 Jul 2005 01:07:56 +0200
Subject: [Python-Dev] [C++-sig]    GCC version compatibility
In-Reply-To: <20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de>	<uu0j6p7z1.fsf@boost-consulting.com>	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>	<u8y0hl45u.fsf@boost-consulting.com>
	<42CEF948.3010908@v.loewis.de>	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>	<42D0D215.9000708@v.loewis.de>	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>	<u64vidbru.fsf@boost-consulting.com>
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <42D2FBCC.2090301@v.loewis.de>

Christoph Ludwig wrote:
> Yes, but on ELF/Linux the default configuration should be --without-cxx
> in the first place. If the build instructions make it sufficiently clear that
> you should prefer this configuration whenever possible then this should be a
> non-issue on platforms like ELF/Linux.

Some users will complain about this. Specifying --without-cxx also
causes configure not to look for a C++ compiler, meaning that distutils
won't know what the C++ compiler is, meaning that it will link extension
modules with the C compiler instead.

Regards,
Martin

From tim.peters at gmail.com  Tue Jul 12 01:19:12 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 11 Jul 2005 19:19:12 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <2mr7e5tz9f.fsf@starship.python.net>
References: <u64vmycwv.fsf@boost-consulting.com>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
	<2mr7e5tz9f.fsf@starship.python.net>
Message-ID: <1f7befae05071116196c5316e5@mail.gmail.com>

[Michael Hudson]
> --with-fpectl, for example.  Does anyone lurking here actually use
> that, know what it does and require the functionality?  Inquiring
> minds want to know.

I know what it intends to do:  fpectlmodule.c intends to enable the HW
FPU divide-by-0, overflow, and invalid operation traps; if any of
those traps trigger, raise the C-level SIGFPE signal; and convert
SIGFPE to a Python-level FloatingPointError exception.  The comments
in pyfpe.h explain this best.

From dave at boost-consulting.com  Tue Jul 12 01:39:50 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 11 Jul 2005 19:39:50 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <42D2F2F9.4070106@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Tue, 12 Jul 2005 00:30:17 +0200")
References: <u64vmycwv.fsf@boost-consulting.com> <42CD3052.6000704@acm.org>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
	<ueka6dc11.fsf@boost-consulting.com> <42D18E9D.8040701@v.loewis.de>
	<uwtny8eb8.fsf@boost-consulting.com> <42D21361.9040708@v.loewis.de>
	<uk6jx8qof.fsf@boost-consulting.com> <42D2F2F9.4070106@v.loewis.de>
Message-ID: <uslyk29q1.fsf@boost-consulting.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>>>>I don't see how that works.  Somehow we need to decide whether to put
>>>>main in ccpython.o in the first place, don't we?
>>>
>
> You wouldn't have to ask these questions if you had investigated the
> answers yourself.

The questions should have been more precisely phrased as, "Do you mean
to say <whatever>?"  Since your statements about the code have not
always been accurate (not blaming you; everyone makes mistakes) I'd
still need to know how you intend your statements to be interpreted,
not only how they correlate with the code.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From kbk at shore.net  Tue Jul 12 06:11:56 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Tue, 12 Jul 2005 00:11:56 -0400 (EDT)
Subject: [Python-Dev] Weekly Python Patch/Bug Summary
Message-ID: <200507120411.j6C4Bu9Y030858@bayview.thirdcreek.com>

Patch / Bug Summary
___________________

Patches :  349 open ( +1) /  2880 closed ( +1) /  3229 total ( +2)
Bugs    :  897 open ( -1) /  5119 closed (+16) /  6016 total (+15)
RFE     :  194 open ( +1) /   170 closed ( +0) /   364 total ( +1)

New / Reopened Patches
______________________

PEP 343 draft documentation  (2005-07-07)
       http://python.org/sf/1234057  opened by  Nick Coghlan

PEP 343 implementation  (2005-07-11)
       http://python.org/sf/1235943  opened by  Michael Hudson

Patches Closed
______________

Allow weak referencing of classic classes  (2005-04-03)
       http://python.org/sf/1175850  closed by  glchapman

New / Reopened Bugs
___________________

Pickle protocols 1, 2 can't handle "inf" floats.  (2005-07-06)
CLOSED http://python.org/sf/1233578  opened by  Charles

getpass.getpass() performs differently on Windows vs *nix  (2005-07-07)
       http://python.org/sf/1233785  opened by  Darryl Dixon

tkFileDialog.askopen... fails when dir=""  (2005-07-06)
       http://python.org/sf/1233799  opened by  Russell Owen

datetime.strftime %s  (2005-07-07)
       http://python.org/sf/1234123  opened by  Peter Kleiweg

'insufficient disk space' message wrong (msi on win xp pro)  (2005-07-07)
       http://python.org/sf/1234328  opened by  Patrick Vrijlandt

configure: error: cannot compute sizeof (int), 77  (2005-07-07)
       http://python.org/sf/1234473  opened by  Tekhne

filecmp.cmp's "shallow" option  (2005-07-08)
       http://python.org/sf/1234674  opened by  Mendez

Admin privs required for Windows?  (2005-07-08)
CLOSED http://python.org/sf/1234850  opened by  Tim Peters

Tutorial Section 6.3 example wrong  (2005-07-08)
CLOSED http://python.org/sf/1234956  opened by  Phoebus Chen

ConfigParser generating strings I can't compare  (2005-07-08)
CLOSED http://python.org/sf/1234965  opened by  Robert Guico

Lock.acquire treats only 1 as True  (2005-07-08)
CLOSED http://python.org/sf/1234979  opened by  Chris Perkins

using some_re.sub() often imports sre.__doc__  (2005-07-09)
       http://python.org/sf/1234985  opened by  Steve Alexander

debug info file descriptor of tarfile is inconsistent  (2005-07-10)
       http://python.org/sf/1235266  opened by  George Yoshida

Inconsistent singleton constructor messages  (2005-07-10)
CLOSED http://python.org/sf/1235569  opened by  Pavel Pergamenshchik

codecs.StreamRecoder.next doesn't encode  (2005-07-10)
       http://python.org/sf/1235646  opened by  Sebastian Wangnick

crashes in bgen wrappers  (2005-07-11)
       http://python.org/sf/1236090  opened by  Michael Hudson

Bugs Closed
___________

openssl-0.9.8 requires _ssl.mak change  (2005-07-06)
       http://python.org/sf/1233049  closed by  loewis

chr() returns ? when input > 127 in OS X  (2005-07-02)
       http://python.org/sf/1231488  closed by  loewis

Build failure  (2005-06-30)
       http://python.org/sf/1230161  closed by  ceramond

Pickle protocols 1, 2 can't handle "inf" floats.  (2005-07-06)
       http://python.org/sf/1233578  closed by  mwh

Admin privs required for Windows?  (2005-07-08)
       http://python.org/sf/1234850  closed by  loewis

Tutorial Section 6.3 example wrong  (2005-07-08)
       http://python.org/sf/1234956  closed by  birkenfeld

ConfigParser generating strings I can't compare  (2005-07-08)
       http://python.org/sf/1234965  closed by  tim_one

Lock.acquire treats only 1 as True  (2005-07-08)
       http://python.org/sf/1234979  closed by  birkenfeld

function and method objects confounded in Tutorial  (2004-06-09)
       http://python.org/sf/969757  closed by  birkenfeld

Inconsistent singleton constructor messages  (2005-07-10)
       http://python.org/sf/1235569  closed by  rhettinger

PyObject_Realloc bug in obmalloc.c  (2005-04-19)
       http://python.org/sf/1185883  closed by  tim_one

Need locale arg to strftime()  (2005-06-13)
       http://python.org/sf/1219840  closed by  bcannon

``from sys import stdin,`` doesn't raise a SyntaxError  (2005-04-25)
       http://python.org/sf/1190012  closed by  bcannon

[AST] distinct code objects not created  (2005-04-25)
       http://python.org/sf/1190011  closed by  bcannon

[AST] automatic unpacking of arguments broken  (2005-04-19)
       http://python.org/sf/1186353  closed by  bcannon

[AST] genexps get scoping wrong  (2005-04-19)
       http://python.org/sf/1186195  closed by  bcannon


From nyamatongwe at gmail.com  Tue Jul 12 08:53:24 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Tue, 12 Jul 2005 16:53:24 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <42D28242.4060306@egenix.com>
References: <d9mmd6$gjf$1@sea.gmane.org> <y88j3pqo.fsf@python.net>
	<50862ebd05070805431808b7e5@mail.gmail.com> <wto1wdzv.fsf@python.net>
	<50862ebd05070820506a829c45@mail.gmail.com>
	<42CFAFBD.2010202@egenix.com>
	<50862ebd0507090604290df5f6@mail.gmail.com>
	<ca471dc205070911216a57ff6e@mail.gmail.com>
	<50862ebd05071106553fba99cb@mail.gmail.com>
	<42D28242.4060306@egenix.com>
Message-ID: <50862ebd05071123533d2323bb@mail.gmail.com>

M.-A. Lemburg:

> > 2) Return unicode when the text can not be represented in ASCII. This
> > will cause a change of behaviour for existing code which deals with
> > non-ASCII data.
> 
> +1 on this one (s/ASCII/Python's default encoding).

   I assume you mean the result of sys.getdefaultencoding() here.
Unless much of the Python library is modified to use the default
encoding, this will break. The problem is that different implicit
encodings are being used for reading data and for accessing files.
When calling a function, such as open, with a byte string, Python
passes that byte string through to Windows which interprets it as
being encoded in CP_ACP. When this differs from
sys.getdefaultencoding() there will be a mismatch.

   Say I have been working on a machine set up for Australian English
(or other Western European locale) but am working with Russian data so
have set Python's default encoding to cp1251. With this simple script,
g.py:

import sys
print file(sys.argv[1]).read()

   I process a file called '?.txt' with contents "European Euro" to produce

C:\zed>python_d g.py ?.txt
European Euro

   With the proposed modification, sys.argv[1] u'\u20ac.txt' is
converted through cp1251 to '\x88.txt' as the Euro is located at 0x88
in CP1251. The operating system is then asked to open '\x88.txt' which
it interprets through CP_ACP to be u'\u02c6.txt' ('?.txt') which then
fails. If you are very unlucky there will be a file called '?.txt' so
the call will succeed and produce bad data.

   Simulating with str(sys.argvu[1]):

C:\zed>python_d g.py ?.txt
Traceback (most recent call last):
  File "g.py", line 2, in ?
    print file(str(sys.argvu[1])).read()
IOError: [Errno 2] No such file or directory: '\x88.txt'

> -1: code pages are evil and the reason why Unicode was invented
> in the first place. This would be a step back in history.

   Features used to specify files (sys.argv, os.environ, ...) should
match functions used to open and perform other operations with files
as they do currently. This means their encodings should match.

   Neil

From cludwig at cdc.informatik.tu-darmstadt.de  Tue Jul 12 09:47:55 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Tue, 12 Jul 2005 09:47:55 +0200
Subject: [Python-Dev] [C++-sig]    GCC version compatibility
In-Reply-To: <42D2FBCC.2090301@v.loewis.de>
References: <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<u64vidbru.fsf@boost-consulting.com>
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D2FBCC.2090301@v.loewis.de>
Message-ID: <20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>

On Tue, Jul 12, 2005 at 01:07:56AM +0200, "Martin v. L?wis" wrote:
> Christoph Ludwig wrote:
> > Yes, but on ELF/Linux the default configuration should be --without-cxx
> > in the first place. If the build instructions make it sufficiently clear that
> > you should prefer this configuration whenever possible then this should be a
> > non-issue on platforms like ELF/Linux.
> 
> Some users will complain about this. Specifying --without-cxx also
> causes configure not to look for a C++ compiler, meaning that distutils
> won't know what the C++ compiler is, meaning that it will link extension
> modules with the C compiler instead.

If I understood Dave Abraham's reply somewhere above in this thread correctly
then you can build different C++ extension modules with different C++
compilers on ELF/Linux. (I don't have the time right now to actually try it,
sorry.) There is no need to fix the C++ compiler as soon as python is built.

If distutils builds C++ extensions with the C compiler then I consider this a
bug in distutils because it is unlikely to work. (Unless the compiler can
figure out from the source file suffixes in the compilation step *and* some
info in the object files in the linking step that it is supposed to act like a
C++ compiler. None of the compilers I am familiar with does the latter.)
distutils should rather look for a C++ compiler in the PATH or explicitly ask
the user to specify the command that calls the C++ compiler.

It is different if --with-cxx=<compiler> was used. I agree that in this case
distutils should use <compiler> to build C++ extensions.

(distutils does not behave correctly when building C++ extensions anyway. It
calls the C compiler to compile the C++ source files and passes options that
gcc accepts only in C mode. The compiler version I am using is docile and only
issues warnings. But these warnings are unnecessary and and I would not blame
gcc if the next compiler release refused to compile C++ sources if the command
line contains C specific options. But the distutils mailing list is a better
place to bring this eventually up, I guess.)

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html


From martin at v.loewis.de  Tue Jul 12 10:19:20 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 12 Jul 2005 10:19:20 +0200
Subject: [Python-Dev] [C++-sig]    GCC version compatibility
In-Reply-To: <20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
References: <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<u64vidbru.fsf@boost-consulting.com>
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D2FBCC.2090301@v.loewis.de>
	<20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <42D37D08.8020405@v.loewis.de>

Christoph Ludwig wrote:
> If I understood Dave Abraham's reply somewhere above in this thread correctly
> then you can build different C++ extension modules with different C++
> compilers on ELF/Linux. (I don't have the time right now to actually try it,
> sorry.) There is no need to fix the C++ compiler as soon as python is built.

There is, somewhat: how do you know the name of the C++ compiler?

> If distutils builds C++ extensions with the C compiler then I consider this a
> bug in distutils because it is unlikely to work. (Unless the compiler can
> figure out from the source file suffixes in the compilation step *and* some
> info in the object files in the linking step that it is supposed to act like a
> C++ compiler. None of the compilers I am familiar with does the latter.)
> distutils should rather look for a C++ compiler in the PATH or explicitly ask
> the user to specify the command that calls the C++ compiler.

How should it do that? The logic is quite involved, and currently,
distutils relies on configure to figure it out. If you think this should
be changed, please contribute a patch.

> (distutils does not behave correctly when building C++ extensions anyway. It
> calls the C compiler to compile the C++ source files and passes options that
> gcc accepts only in C mode. The compiler version I am using is docile and only
> issues warnings. But these warnings are unnecessary and and I would not blame
> gcc if the next compiler release refused to compile C++ sources if the command
> line contains C specific options. But the distutils mailing list is a better
> place to bring this eventually up, I guess.)

The best way to "bring this up" is to contribute a patch. "Bringing it
up" in the sense of sending an email message to some mailing list likely
has no effect whatsoever.

Regards,
Martin

From mal at egenix.com  Tue Jul 12 10:37:14 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 12 Jul 2005 10:37:14 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE
	for	review)
In-Reply-To: <50862ebd05071123533d2323bb@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<y88j3pqo.fsf@python.net>	<50862ebd05070805431808b7e5@mail.gmail.com>
	<wto1wdzv.fsf@python.net>	<50862ebd05070820506a829c45@mail.gmail.com>	<42CFAFBD.2010202@egenix.com>	<50862ebd0507090604290df5f6@mail.gmail.com>	<ca471dc205070911216a57ff6e@mail.gmail.com>	<50862ebd05071106553fba99cb@mail.gmail.com>	<42D28242.4060306@egenix.com>
	<50862ebd05071123533d2323bb@mail.gmail.com>
Message-ID: <42D3813A.5030208@egenix.com>

Hi Neil,

>>>2) Return unicode when the text can not be represented in ASCII. This
>>>will cause a change of behaviour for existing code which deals with
>>>non-ASCII data.
>>
>>+1 on this one (s/ASCII/Python's default encoding).
> 
> 
>    I assume you mean the result of sys.getdefaultencoding() here.

Yes.

The default encoding is the encoding that Python assumes when
auto-converting a string to Unicode. It is normally set to ASCII,
but a user may want to use a different encoding.

However, we've always made it very clear that the user is on his
own when chainging the ASCII default to something else.

> Unless much of the Python library is modified to use the default
> encoding, this will break. The problem is that different implicit
> encodings are being used for reading data and for accessing files.
> When calling a function, such as open, with a byte string, Python
> passes that byte string through to Windows which interprets it as
> being encoded in CP_ACP. When this differs from
> sys.getdefaultencoding() there will be a mismatch.

As I said: code pages are evil :-)

>    Say I have been working on a machine set up for Australian English
> (or other Western European locale) but am working with Russian data so
> have set Python's default encoding to cp1251. With this simple script,
> g.py:
> 
> import sys
> print file(sys.argv[1]).read()
> 
>    I process a file called '?.txt' with contents "European Euro" to produce
> 
> C:\zed>python_d g.py ?.txt
> European Euro
> 
>    With the proposed modification, sys.argv[1] u'\u20ac.txt' is
> converted through cp1251 

Actually, it is not: if you pass in a Unicode argument to
one of the file I/O functions and the OS supports Unicode
directly or at least provides the notion of a file system
encoding, then the file I/O should use the Unicode APIs
of the OS or convert the Unicode argument to the file system
encoding. AFAIK, this is how posixmodule.c already works
(more or less).

I was suggesting that OS filename output APIs such as os.listdir()
should return strings, if the filename matches the default
encoding, and Unicode, if not.

On input, file I/O APIs should accept both strings using
the default encoding and Unicode. How these inputs are then
converted to suit the OS is up to the OS abstraction layer, e.g.
posixmodule.c.

Note that the posixmodule currently does not recode string
arguments: it simply passes them to the OS as-is, assuming
that they are already encoded using the file system encoding.
Changing this is easy, though: instead of using the "et"
getargs format specifier, you'd have to use "es". The latter
recodes strings based on the default encoding assumption to
whatever other encoding you specify.

> to '\x88.txt' as the Euro is located at 0x88
> in CP1251. The operating system is then asked to open '\x88.txt' which
> it interprets through CP_ACP to be u'\u02c6.txt' ('?.txt') which then
> fails. If you are very unlucky there will be a file called '?.txt' so
> the call will succeed and produce bad data.
> 
>    Simulating with str(sys.argvu[1]):
> 
> C:\zed>python_d g.py ?.txt
> Traceback (most recent call last):
>   File "g.py", line 2, in ?
>     print file(str(sys.argvu[1])).read()
> IOError: [Errno 2] No such file or directory: '\x88.txt'

See above: this is what I'd consider a bug in posixmodule.c

>>-1: code pages are evil and the reason why Unicode was invented
>>in the first place. This would be a step back in history.
> 
> 
>    Features used to specify files (sys.argv, os.environ, ...) should
> match functions used to open and perform other operations with files
> as they do currently. This means their encodings should match.

Right. However, most of these APIs currently either don't
make any assumption on the strings contents and simply pass
them around, or they assume that these strings use the file
system encoding - which, like in the example you gave above,
can be different from the default encoding.

To untie this Gordian Knot, we should use strings and Unicode
like they are supposed to be used (in the context of text
data):

* strings are fine for text data that is encoded using
  the default encoding

* Unicode should be used for all text data that is not
  or cannot be encoded in the default encoding

Later on in Py3k, all text data should be stored in Unicode
and all binary data in some new binary type.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 12 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From mwh at python.net  Tue Jul 12 12:28:00 2005
From: mwh at python.net (Michael Hudson)
Date: Tue, 12 Jul 2005 11:28:00 +0100
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <1f7befae05071116196c5316e5@mail.gmail.com> (Tim Peters's
	message of "Mon, 11 Jul 2005 19:19:12 -0400")
References: <u64vmycwv.fsf@boost-consulting.com>
	<uy88ivgg0.fsf@boost-consulting.com>
	<17101.16300.736797.378762@montanaro.dyndns.org>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
	<2mr7e5tz9f.fsf@starship.python.net>
	<1f7befae05071116196c5316e5@mail.gmail.com>
Message-ID: <2mmzostj2n.fsf@starship.python.net>

Tim Peters <tim.peters at gmail.com> writes:

> [Michael Hudson]
>> --with-fpectl, for example.  Does anyone lurking here actually use
>> that, know what it does and require the functionality?  Inquiring
>> minds want to know.
>
> I know what it intends to do:

Surprise!

> fpectlmodule.c intends to enable the HW FPU divide-by-0, overflow,
> and invalid operation traps; if any of those traps trigger, raise
> the C-level SIGFPE signal; and convert SIGFPE to a Python-level
> FloatingPointError exception.  The comments in pyfpe.h explain this
> best.

But do you use it?  I know what it intends to do too, but I don't use
it.  The questions I asked were in the order they were for a reason.

Cheers,
mwh

-- 
 <cube> If you are anal, and you love to be right all the time, C++
   gives you a multitude of mostly untimportant details to fret about
   so you can feel good about yourself for getting them "right", 
   while missing the big picture entirely       -- from Twisted.Quotes

From ncoghlan at gmail.com  Tue Jul 12 13:20:06 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 12 Jul 2005 21:20:06 +1000
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <17106.31652.667441.511084@montanaro.dyndns.org>
References: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>	<17102.64600.669006.871379@montanaro.dyndns.org>	<2mvf3htzjw.fsf@starship.python.net>
	<17106.31652.667441.511084@montanaro.dyndns.org>
Message-ID: <42D3A766.90705@gmail.com>

Skip Montanaro wrote:
> After seeing so many messages about "with" statements my eyes began to glaze
> over, so I stopped following that thread.  Then I saw mention of "context
> manager" with no reference to any PEPs or to the with statement to provide
> context.

The main outcome of the PEP 343 terminology discussion was some proposed 
documentation I put on the Sourceforge patch tracker ([1]). The patch is 
currently assigned to Raymond (since he started the terminology discussion) 
but any other reviews would be welcome.

Since SF currently doesn't want to play, and the proposed documentation isn't 
that long, I've included the latest version below for anyone who wants to read it.

> None of the context-providing messages seemed to have been indexed
> by Google when I checked, so searching for "Python context manager" failed
> to return anything useful.  Hence the post.

Google appears to have spidered the list archives some time today, so anyone 
else doing the same search should get some relevant hits.

Cheers,
Nick.

[1] http://www.python.org/sf/1234057
==========================================
With Statements and Context Management

A frequent need in programming is to ensure a particular action is
taken after a specific section of code has been executed (such as
closing a file or releasing a lock). Traditionally, this is handled
using 'try'/'finally' statements. However, that approach can lead
to the reproduction of non-trivial amounts of boilerplate whenever
the action needs to be invoked.

A simpler way to achieve this in Python is to use the 'with' statement
along with the appropriate context manager. Context managers define an
action which is taken to enter the context and a second action to
exit the context (usually restoring the environment that existed
before the context was entered). The 'with' statement ensures that the
context is entered and exited at the appropriate times (that is,
before and after the execution of the suite contained in the 'with'
statement).

The precise behaviour of the 'with' statement is governed by the
supplied context manager - an object which supports the context
management protocol. This protocol consists of two methods:

      __enter__(self):
        Context managers use this method to enter the desired context
      before the execution of the contained suite.
        This method is called without arguments before execution of
      the contained suite starts. If the 'as' clause of the 'with'
      statement is used, the value returned from this method is
      assigned to the specified target.
        Many context managers will return self from this method, but
      returning a different object may make sense for some managers
      (for example, see the 'closing' suite manager described below).

      __exit__(self, exc_type, exc_value, exc_traceback):
        Context managers use this method to exit the context after
      execution of the contained suite.
        This method is called after execution of the contained suite
      is completed. If execution completed due to an exception, the
      details of that exception are passed as arguments. Otherwise,
      all three arguments are set to None.
        If exception details are passed in, and this method returns
      without incident, then the original exception continues to
      propagate. Otherwise, the exception raised by this method will
      replace the original exception.


Using Contexts to Manage Resources

The simplest use of context management is to strictly control the
handling of key resources (such as files, generators, database
connections, synchronisation locks).

These resource managers will generally acquire the resource in their
__enter__ method, although some resource managers may accept the
resource to be managed as an argument to the constructor or acquire it
during construction. Resource managers will then release the resource
in their __exit__ method.

For example, the following context manager allows prompt closure of
any resource with a 'close' method (e.g. a generator or file):

      class closing(object):
          def __init__(self, resource):
              self.resource = resource

          def __enter__(self):
              return self.resource

          def __exit__(self, *exc_info):
              self.resource.close()


     with closing(my_generator()) as g:
         # my_generator() is assigned to g via call to __enter__()
         for item in g:
             print item
     # g is closed as the with statement ends

Some resources (such as threading.Lock) support the context management
protocol natively, allowing them to be used directly in 'with'
statements. The meaning of the established context will depend on the
specific resource. In the case of threading.Lock, the lock is acquired
by the __enter__ method, and released by the __exit__ method.

   with the_lock:
       # Suite is executed with the_lock held
   # the_lock is released as the with statement ends


More Context Management Examples

While resource management may be the most obvious use of the context
management protocol, many more uses are possible (otherwise it would
have been called the resource management protocol!).

For example, when used as a context manager, a decimal.Context object
will set itself as the current Decimal arithmetic context in the
__enter__ method, and then automatically revert back to the previous
Decimal arithmetic context in the __exit__ method. This allows the
code in the contained suite to manipulate the Decimal arithmetic
context freely, without needing to worry about manually undoing any
changes.

     with decimal.getcontext() as ctx:
         ctx.prec = 48
         # Perform high precision calculations within the context
     # Precision reverts to default here

Another example is the use of contexts to handle insertion of the
appropriate start and end tags when generating HTML:

     class tag(object):
         def __init__(self,name):
             self.name = name

         def __enter__(self):
             print "<%s>" % self.name

         def __exit__(self, exc_type, *exc_details):
             if exc_type is None:
                 print "</%s>" % self.name


     with tag('html'):
        with tag('body'):
           with tag('h1'):
              print "Some heading"
           with tag('p'):
              print "This is paragraph 1"
           with tag('p'):
              print "This is paragraph 2"
           with tag('h2'):
              print "Another heading"

Some other possibilities for context management include automatic
exception logging and handling of database transactions.


Using Generators to Define Context Managers

In conjunction with the 'contextmanager' decorator, Python's
generators provide a convenient way to implement the context
management protocol, and share state between the __enter__ and
__exit__ methods.

The generator must yield exactly once during normal execution. The
context manager's __enter__ method executes the generator up to that
point, and the value yielded is returned. The remainder of the
generator is executed by the context manager's __exit__ method. Any
exceptions that occur in the managed context will be injected into the
generator at the location of the yield statement.

For example, here are the 'closing' and 'tag' context manager examples
written using generators:

      @contextmanager
      def closing(resource):
          try:
              yield resource
          finally:
              resource.close()


      @contextmanager
      def tag(name):
          print "<%s>" % name
          yield None
          print "</%s>" % name

The operation of the contextmanager decorator is described by the
following Python equivalent (although the exact error messages may
differ):

      class ContextWrapper(object):
          def __init__(self, gen):
              self.gen = gen

          def __enter__(self):
              try:
                  return self.gen.next()
              except StopIteration:
                  raise RuntimeError("generator didn't yield")

          def __exit__(self, type, value, traceback):
              if type is None:
                  try:
                      self.gen.next()
                  except StopIteration:
                      return
                  else:
                      raise RuntimeError("generator didn't stop")
              else:
                  try:
                      self.gen.throw(type, value, traceback)
                  except (type, StopIteration):
                      return
                  else:
                      raise RuntimeError("generator didn't stop")


      def contextmanager(func):
          def factory(*args, **kwds):
              return ContextWrapper(func(*args, **kwds))
          factory.__name__ = func.__name__
          factory.__doc__ = func.__doc__
          factory.__dict__ = func.__dict__
          return factory
==========================================



-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From mcherm at mcherm.com  Tue Jul 12 16:10:49 2005
From: mcherm at mcherm.com (Michael Chermside)
Date: Tue, 12 Jul 2005 07:10:49 -0700
Subject: [Python-Dev] Adding the 'path' module (was Re:
	Some	RFEfor	review)
Message-ID: <20050712071049.1raxuol6ph748gco@login.werra.lunarpages.com>

M A Lemburg writes:
> we should use strings and Unicode
> like they are supposed to be used (in the context of text
> data):
>
> * strings are fine for text data that is encoded using
>   the default encoding
>
> * Unicode should be used for all text data that is not
>   or cannot be encoded in the default encoding
>
> Later on in Py3k, all text data should be stored in Unicode
> and all binary data in some new binary type.

Wow. That is the most succinct and clear explanation of how to
use unicode in Python that I think I've ever heard. It might
even be simple enough for _me_ to understand it! I think I'm
going to go frame this and have it posted in my cubical.

-- Michael Chermside


From gvanrossum at gmail.com  Tue Jul 12 16:38:38 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Tue, 12 Jul 2005 07:38:38 -0700
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFEfor
	review)
In-Reply-To: <20050712071049.1raxuol6ph748gco@login.werra.lunarpages.com>
References: <20050712071049.1raxuol6ph748gco@login.werra.lunarpages.com>
Message-ID: <ca471dc205071207382152f2d4@mail.gmail.com>

QOTF candidate; should add that the default encoding is usually ASCII.

On 7/12/05, Michael Chermside <mcherm at mcherm.com> wrote:
> M A Lemburg writes:
> > we should use strings and Unicode
> > like they are supposed to be used (in the context of text
> > data):
> >
> > * strings are fine for text data that is encoded using
> >   the default encoding
> >
> > * Unicode should be used for all text data that is not
> >   or cannot be encoded in the default encoding
> >
> > Later on in Py3k, all text data should be stored in Unicode
> > and all binary data in some new binary type.
> 
> Wow. That is the most succinct and clear explanation of how to
> use unicode in Python that I think I've ever heard. It might
> even be simple enough for _me_ to understand it! I think I'm
> going to go frame this and have it posted in my cubical.
> 
> -- Michael Chermside
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/)

From gvanrossum at gmail.com  Tue Jul 12 16:41:05 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Tue, 12 Jul 2005 07:41:05 -0700
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <2mmzostj2n.fsf@starship.python.net>
References: <u64vmycwv.fsf@boost-consulting.com>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
	<2mr7e5tz9f.fsf@starship.python.net>
	<1f7befae05071116196c5316e5@mail.gmail.com>
	<2mmzostj2n.fsf@starship.python.net>
Message-ID: <ca471dc205071207412663dde@mail.gmail.com>

Nobody uses it. It should be ripped out. If someone disagrees, let
them speak up.

On 7/12/05, Michael Hudson <mwh at python.net> wrote:
> Tim Peters <tim.peters at gmail.com> writes:
> 
> > [Michael Hudson]
> >> --with-fpectl, for example.  Does anyone lurking here actually use
> >> that, know what it does and require the functionality?  Inquiring
> >> minds want to know.
> >
> > I know what it intends to do:
> 
> Surprise!
> 
> > fpectlmodule.c intends to enable the HW FPU divide-by-0, overflow,
> > and invalid operation traps; if any of those traps trigger, raise
> > the C-level SIGFPE signal; and convert SIGFPE to a Python-level
> > FloatingPointError exception.  The comments in pyfpe.h explain this
> > best.
> 
> But do you use it?  I know what it intends to do too, but I don't use
> it.  The questions I asked were in the order they were for a reason.
> 
> Cheers,
> mwh
> 
> --
>  <cube> If you are anal, and you love to be right all the time, C++
>    gives you a multitude of mostly untimportant details to fret about
>    so you can feel good about yourself for getting them "right",
>    while missing the big picture entirely       -- from Twisted.Quotes
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/)

From nick.bastin at gmail.com  Tue Jul 12 17:20:39 2005
From: nick.bastin at gmail.com (Nicholas Bastin)
Date: Tue, 12 Jul 2005 11:20:39 -0400
Subject: [Python-Dev] [C++-sig] GCC version compatibility
In-Reply-To: <20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
References: <uu0j6p7z1.fsf@boost-consulting.com>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<u64vidbru.fsf@boost-consulting.com>
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D2FBCC.2090301@v.loewis.de>
	<20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <66d0a6e1050712082033087799@mail.gmail.com>

On 7/12/05, Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> wrote:
> If distutils builds C++ extensions with the C compiler then I consider this a
> bug in distutils because it is unlikely to work. (Unless the compiler can
> figure out from the source file suffixes in the compilation step *and* some
> info in the object files in the linking step that it is supposed to act like a
> C++ compiler. None of the compilers I am familiar with does the latter.)
> distutils should rather look for a C++ compiler in the PATH or explicitly ask
> the user to specify the command that calls the C++ compiler.

You practically always have to use --compiler with distutils when
building C++ extensions anyhow, and even then it rarely does what I
would consider 'The Right Thing(tm)'.  The problem is the distutils
core assumption that you want to build extension modules with the same
compiler options that you built Python with, is in many cases the
wrong thing to do for C++ extension modules, even if you built Python
with --with-cxx.  This is even worse on windows where the MSVC
compiler, until very recently, was crap for C++, and you really needed
to use another compiler for C++, but Python was always built using
MSVC (unless you jumped through hoops of fire).

The problem is that this is much more complicated than it seems - you
can't just ask the user for the C++ compiler, you really need to
provide an abstraction layer for all of the compiler and linker flags,
so that a user could specify what those flags are for their compiler
of choice.  Of course, once you've done that, the user might as well
have just written a new Compiler class for distutils, which wouldn't
pay any attention to how Python was built (other than where Python.h
is).

--
Nick

From tim.peters at gmail.com  Tue Jul 12 18:19:14 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 12 Jul 2005 12:19:14 -0400
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <2mmzostj2n.fsf@starship.python.net>
References: <u64vmycwv.fsf@boost-consulting.com>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
	<2mr7e5tz9f.fsf@starship.python.net>
	<1f7befae05071116196c5316e5@mail.gmail.com>
	<2mmzostj2n.fsf@starship.python.net>
Message-ID: <1f7befae05071209193592aa66@mail.gmail.com>

[Michael Hudson]
>>> --with-fpectl, for example.  Does anyone lurking here actually use
>>> that, know what it does and require the functionality?  Inquiring
>>> minds want to know.

[Tim, explains what it intends to do]
>> ...

[Michael]
> But do you use it?  I know what it intends to do too,

Then why ask what it does?  You're asking a lot of questions lately
that you're irked by when you get an answer <0.9 wink>.

> but I don't use it.  The questions I asked were in the order they were
> for a reason.

No, I don't use it -- last I looked seriously (which was years ago),
it didn't work on Windows.  I don't know of anyone who does use it. 
The functionality is highly desired by some numeric programmers, in
some parts of some of their apps, although they'd like finer control
(like don't gripe about divide-by-0 but do gripe about overflow in
function A, and don't gripe about anything in function B, and only
gripe about invalid operation in the 23rd line of function C).

From gvanrossum at gmail.com  Tue Jul 12 18:29:34 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Tue, 12 Jul 2005 09:29:34 -0700
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <42D3A766.90705@gmail.com>
References: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>
	<17102.64600.669006.871379@montanaro.dyndns.org>
	<2mvf3htzjw.fsf@starship.python.net>
	<17106.31652.667441.511084@montanaro.dyndns.org>
	<42D3A766.90705@gmail.com>
Message-ID: <ca471dc20507120929141d22bc@mail.gmail.com>

FWIW, I've updated PEP 343 to use @contextmanager and class
ContextWrapper. Please proofread.

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

From tjreedy at udel.edu  Tue Jul 12 21:38:44 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 12 Jul 2005 15:38:44 -0400
Subject: [Python-Dev] Possible context managers in stdlib
References: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>	<17102.64600.669006.871379@montanaro.dyndns.org>	<2mvf3htzjw.fsf@starship.python.net><17106.31652.667441.511084@montanaro.dyndns.org>
	<42D3A766.90705@gmail.com>
Message-ID: <db1685$sb5$1@sea.gmane.org>


"Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
news:42D3A766.90705 at gmail.com...
> The main outcome of the PEP 343 terminology discussion was some proposed
> documentation I put on the Sourceforge patch tracker ([1]).

Is this a proposal for the Language Reference manual?

> [1] http://www.python.org/sf/1234057
> ==========================================
> With Statements and Context Management
>
> A frequent need in programming ...
>
> A simpler way to achieve this in Python is to use the 'with' statement
> along with the appropriate context manager.

Somewhere about here we need the syntax itself.

> Context managers define an...
>      the contained suite starts. If the 'as' clause of the 'with'

Else this does not mean much.
...
> The simplest use of context management is to strictly control the
> handling of key resources (such as files, generators, database
> connections, synchronisation locks).

I have a little trouble seeing generators (as opposed to iterables) as 
resources needing management.

> For example, the following context manager allows prompt closure of
> any resource with a 'close' method (e.g. a generator or file):

And I was not aware that they had close methods.  You mean a iterable (not 
just a file) with both an associated generator and a close?  Or are 
generators gaining close methods (which make no sense to me).  Or are you 
using 'generator' in a different sense?

>      class closing(object):
>          def __init__(self, resource):
>              self.resource = resource
>
>          def __enter__(self):
>              return self.resource
>
>          def __exit__(self, *exc_info):
>              self.resource.close()
>
>
>     with closing(my_generator()) as g:
>         # my_generator() is assigned to g via call to __enter__()
>         for item in g:
>             print item
>     # g is closed as the with statement ends

To me, this should be with closing(my_iterable())... with 'for' calling 
g.__iter__ to get the iterator that is possibly a generator.  Otherwise, I 
don't understand it.

The rest is pretty clear.

Terry J. Reedy




From maparent at gmail.com  Tue Jul 12 23:27:37 2005
From: maparent at gmail.com (Marc-Antoine Parent)
Date: Tue, 12 Jul 2005 17:27:37 -0400
Subject: [Python-Dev] Terminology for PEP 343
References: <5D4AA865-757C-4A6C-A5C7-78A95DA0BB97@acm.org>
Message-ID: <F055A690-C75C-48B8-A7A8-CB15DBA3F64E@acm.org>

Probably late in the game, esp. for an outsider, but I read the  
terminology discussion with interest.
FWIW, I do like Philip's use of context, though I feel that it is a  
very generic word that may clash with many application-level  
classes... For that reason, I also liked "scope" a lot, though it was  
an... expension of that term's usual meaning beyond namespaces.
Anyway, what really struck me all along is that, when reading the  
keyword "with", I always felt that I would replace it with "within",  
which imho fits the context/scope terminology better. Thus "within" a  
"context", we do certain actions... which are fenced with  
__begincontext and __endcontext.
(Oh, yes, fences... What was the original precise computer science  
meaning of that word, again?)

Cheers,
Marc-Antoine


From ncoghlan at gmail.com  Wed Jul 13 00:15:15 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 13 Jul 2005 08:15:15 +1000
Subject: [Python-Dev] Possible context managers in stdlib
In-Reply-To: <db1685$sb5$1@sea.gmane.org>
References: <20050708143922.xs7pj9rswzcwos8w@login.werra.lunarpages.com>	<17102.64600.669006.871379@montanaro.dyndns.org>	<2mvf3htzjw.fsf@starship.python.net><17106.31652.667441.511084@montanaro.dyndns.org>	<42D3A766.90705@gmail.com>
	<db1685$sb5$1@sea.gmane.org>
Message-ID: <42D440F3.4040704@gmail.com>

Terry Reedy wrote:
> "Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
> news:42D3A766.90705 at gmail.com...
> 
>>The main outcome of the PEP 343 terminology discussion was some proposed
>>documentation I put on the Sourceforge patch tracker ([1]).
> 
> Is this a proposal for the Language Reference manual?

No - it's for an entry in the Library reference under 'built-in types', as a 
sibling to the current documentation of the iteration protocol.

The 'with' statement itself would have to be documented along with the rest of 
the grammar.

>>A simpler way to achieve this in Python is to use the 'with' statement
>>along with the appropriate context manager.
> 
> Somewhere about here we need the syntax itself.

I'm not sure. We don't reproduce the 'for' loop syntax in the documentation of 
iterators, so should we reproduce the 'with' statement syntax in the 
documentation of context managers?

Again, modelling on the existing documentation of the iteration protocol, I 
would expect the statement syntax to be introduced in the tutorial (e.g. as 
part of Section 8.6, where try/finally is introduced).

>>Context managers define an...
>>     the contained suite starts. If the 'as' clause of the 'with'
> 
> 
> Else this does not mean much.
> ...
> 
>>The simplest use of context management is to strictly control the
>>handling of key resources (such as files, generators, database
>>connections, synchronisation locks).
> 
> I have a little trouble seeing generators (as opposed to iterables) as 
> resources needing management.

PEP 342 adds this, in order to allow 'yield' inside tyr/finally blocks.
> 
> 
>>For example, the following context manager allows prompt closure of
>>any resource with a 'close' method (e.g. a generator or file):
> 
> 
> And I was not aware that they had close methods.  You mean a iterable (not 
> just a file) with both an associated generator and a close?  Or are 
> generators gaining close methods (which make no sense to me).  Or are you 
> using 'generator' in a different sense?

Sorry - these docs assume PEP 342 has been implemented, so generator's have 
close() methods. I was trying to steer clear of files, since we don't know yet 
whether there is going to be an "opening" or "closing" implementation in the 
standard library, or whether files will become context managers. The latter is 
my preference, but Guido didn't seem too keen on the idea last time it was 
brought up.

> 
> 
>>     class closing(object):
>>         def __init__(self, resource):
>>             self.resource = resource
>>
>>         def __enter__(self):
>>             return self.resource
>>
>>         def __exit__(self, *exc_info):
>>             self.resource.close()
>>
>>
>>    with closing(my_generator()) as g:
>>        # my_generator() is assigned to g via call to __enter__()
>>        for item in g:
>>            print item
>>    # g is closed as the with statement ends
> 
> 
> To me, this should be with closing(my_iterable())... with 'for' calling 
> g.__iter__ to get the iterator that is possibly a generator.  Otherwise, I 
> don't understand it.
> 
> The rest is pretty clear.
> 
> Terry J. Reedy
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40email.com
> 


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From nyamatongwe at gmail.com  Wed Jul 13 02:57:49 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Wed, 13 Jul 2005 10:57:49 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <42D3813A.5030208@egenix.com>
References: <d9mmd6$gjf$1@sea.gmane.org> <wto1wdzv.fsf@python.net>
	<50862ebd05070820506a829c45@mail.gmail.com>
	<42CFAFBD.2010202@egenix.com>
	<50862ebd0507090604290df5f6@mail.gmail.com>
	<ca471dc205070911216a57ff6e@mail.gmail.com>
	<50862ebd05071106553fba99cb@mail.gmail.com>
	<42D28242.4060306@egenix.com>
	<50862ebd05071123533d2323bb@mail.gmail.com>
	<42D3813A.5030208@egenix.com>
Message-ID: <50862ebd05071217571163f3c0@mail.gmail.com>

   Hi Marc-Andre,

> >    With the proposed modification, sys.argv[1] u'\u20ac.txt' is
> > converted through cp1251
> 
> Actually, it is not: if you pass in a Unicode argument to
> one of the file I/O functions and the OS supports Unicode
> directly or at least provides the notion of a file system
> encoding, then the file I/O should use the Unicode APIs
> of the OS or convert the Unicode argument to the file system
> encoding. AFAIK, this is how posixmodule.c already works
> (more or less).

   Yes it is. The initial stage is reading the command line arguments.
The proposed modification is to change behaviour when constructing
sys.argv, os.environ or when calling os.listdir to "Return unicode
when the text can not be represented in Python's default encoding". I
take this to mean that when the value can be represented in Python's
default encoding then it is returned as a byte string in the default
encoding.

   Therefore, for the example, the code that sets up sys.argv has to
encode the unicode command line argument into cp1251.

> On input, file I/O APIs should accept both strings using
> the default encoding and Unicode. How these inputs are then
> converted to suit the OS is up to the OS abstraction layer, e.g.
> posixmodule.c.

   This looks to me to be insufficiently compatible with current
behaviour whih accepts byte strings outside the default encoding.
Existing code may call open("?.txt"). This is perfectly legitimate
current Python (with a coding declaration) as "?.txt" is a byte string
and file systems will accept byte string names. Since the standard
default encoding is ASCII, should such code raise UnicodeDecodeError?

> Changing this is easy, though: instead of using the "et"
> getargs format specifier, you'd have to use "es". The latter
> recodes strings based on the default encoding assumption to
> whatever other encoding you specify.

   Don't you want to convert these into unicode rather than another
byte string encoding? It looks to me as though the "es" format always
produces byte strings and the only byte string format that can be
passed to the operating system is the file system encoding which may
not contain all the characters in the default encoding.

   Neil

From martin at v.loewis.de  Wed Jul 13 08:10:33 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 13 Jul 2005 08:10:33 +0200
Subject: [Python-Dev] [C++-sig] GCC version compatibility
In-Reply-To: <66d0a6e1050712082033087799@mail.gmail.com>
References: <uu0j6p7z1.fsf@boost-consulting.com>	
	<u8y0hl45u.fsf@boost-consulting.com>
	<42CEF948.3010908@v.loewis.de>	
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>	
	<42D0D215.9000708@v.loewis.de>	
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>	
	<u64vidbru.fsf@boost-consulting.com>	
	<20050710144946.GB3587@lap200.cdc.informatik.tu-darmstadt.de>	
	<42D2FBCC.2090301@v.loewis.de>	
	<20050712074755.GA2741@lap200.cdc.informatik.tu-darmstadt.de>
	<66d0a6e1050712082033087799@mail.gmail.com>
Message-ID: <42D4B059.1080303@v.loewis.de>

Nicholas Bastin wrote:
> You practically always have to use --compiler with distutils when
> building C++ extensions anyhow, and even then it rarely does what I
> would consider 'The Right Thing(tm)'.  

I see. In that case, I think something should be done about distutils
as well (assuming somebody volunteers): it would be best if this worked
in the usual cases, with some easy way for the setup.py author to
indicate the preferences.

Regards,
Martin

From mwh at python.net  Wed Jul 13 13:36:40 2005
From: mwh at python.net (Michael Hudson)
Date: Wed, 13 Jul 2005 12:36:40 +0100
Subject: [Python-Dev] Linux Python linking with G++?
In-Reply-To: <1f7befae05071209193592aa66@mail.gmail.com> (Tim Peters's
	message of "Tue, 12 Jul 2005 12:19:14 -0400")
References: <u64vmycwv.fsf@boost-consulting.com>
	<ud5putpjj.fsf@boost-consulting.com>
	<17101.37403.452222.396424@montanaro.dyndns.org>
	<upstup7r9.fsf@boost-consulting.com> <42CEFE31.1000800@v.loewis.de>
	<uy88gg399.fsf@boost-consulting.com> <42D0CD7F.3080007@v.loewis.de>
	<2mr7e5tz9f.fsf@starship.python.net>
	<1f7befae05071116196c5316e5@mail.gmail.com>
	<2mmzostj2n.fsf@starship.python.net>
	<1f7befae05071209193592aa66@mail.gmail.com>
Message-ID: <2mirzfszsn.fsf@starship.python.net>

Tim Peters <tim.peters at gmail.com> writes:

> [Michael Hudson]
>>>> --with-fpectl, for example.  Does anyone lurking here actually use
>>>> that, know what it does and require the functionality?  Inquiring
>>>> minds want to know.
>
> [Tim, explains what it intends to do]
>>> ...
>
> [Michael]
>> But do you use it?  I know what it intends to do too,
>
> Then why ask what it does?  You're asking a lot of questions lately
> that you're irked by when you get an answer <0.9 wink>.

Isn't that the Socratic Method?  :) Well, no it's not, but I do ask a
lot of questions fishing for perhaps not the most obvious answer.

>> but I don't use it.  The questions I asked were in the order they were
>> for a reason.
>
> No, I don't use it -- last I looked seriously (which was years ago),
> it didn't work on Windows.

Right, that's what I thought.

> I don't know of anyone who does use it.

Even better!

Cheers,
mwh

-- 
  I really hope there's a catastrophic bug in some future e-mail
  program where if you try and send an attachment it cancels your
  ISP account, deletes your harddrive, and pisses in your coffee
                                                         -- Adam Rixey

From bcannon at gmail.com  Thu Jul 14 03:46:33 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Wed, 13 Jul 2005 18:46:33 -0700
Subject: [Python-Dev] Another SoC student for CVS access
In-Reply-To: <bbaeab1005070713306f1f34b5@mail.gmail.com>
References: <bbaeab1005070713306f1f34b5@mail.gmail.com>
Message-ID: <bbaeab10050713184625778623@mail.gmail.com>

This is taking too long, so I am going to have Floris do his dev work
somewhere else.  Forget about the request.

-Brett

On 7/7/05, Brett Cannon <bcannon at gmail.com> wrote:
> Floris is working on wrapping Hotshot to replace 'profile' and
> replacing pstats so that there will be no more need for 'profile' and
> thus take care of the licensing problem.  He also hopes to make pstats
> faster to use.  And if we are really lucky, get threading working for
> Hotshot.
> 
> It would be great to give him CVS access so he can work in nondist.
> His username is sirolf .  He knows he is not to touch anything outside
> of his directory in nondist.
> 
> -Brett
>

From reinhold-birkenfeld-nospam at wolke7.net  Thu Jul 14 08:45:52 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Thu, 14 Jul 2005 08:45:52 +0200
Subject: [Python-Dev] SF patch #1214889 - file.encoding support
Message-ID: <db51n0$s1t$1@sea.gmane.org>

Hi,

would anyone care to comment about this patch of mine --
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470

It makes file.encoding read-write and lets the write() and writelines() methods
obey it.

Reinhold


-- 
Mail address is perfectly valid!


From mal at egenix.com  Thu Jul 14 09:53:58 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 14 Jul 2005 09:53:58 +0200
Subject: [Python-Dev] SF patch #1214889 - file.encoding support
In-Reply-To: <db51n0$s1t$1@sea.gmane.org>
References: <db51n0$s1t$1@sea.gmane.org>
Message-ID: <42D61A16.4050602@egenix.com>

Reinhold Birkenfeld wrote:
> Hi,
> 
> would anyone care to comment about this patch of mine --
> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470
> 
> It makes file.encoding read-write and lets the write() and writelines() methods
> obey it.

Done. Please see SF.

PS: Please don't use "-nospam" or the like email addresses when posting
to this list. Thanks.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 14 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From reinhold-birkenfeld-nospam at wolke7.net  Thu Jul 14 10:03:13 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Thu, 14 Jul 2005 10:03:13 +0200
Subject: [Python-Dev] SF patch #1214889 - file.encoding support
In-Reply-To: <42D61A16.4050602@egenix.com>
References: <db51n0$s1t$1@sea.gmane.org> <42D61A16.4050602@egenix.com>
Message-ID: <db5681$885$1@sea.gmane.org>

M.-A. Lemburg wrote:
> Reinhold Birkenfeld wrote:
>> Hi,
>> 
>> would anyone care to comment about this patch of mine --
>> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470
>> 
>> It makes file.encoding read-write and lets the write() and writelines() methods
>> obey it.
> 
> Done. Please see SF.
> 
> PS: Please don't use "-nospam" or the like email addresses when posting
> to this list. Thanks.

Why? This address is perfectly valid (as is written in my signature), and almost
completely spam-free.

Reinhold

-- 
Mail address is perfectly valid!


From mal at egenix.com  Thu Jul 14 13:04:46 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 14 Jul 2005 13:04:46 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE
	for	review)
In-Reply-To: <50862ebd05071217571163f3c0@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org> <wto1wdzv.fsf@python.net>	
	<50862ebd05070820506a829c45@mail.gmail.com>	
	<42CFAFBD.2010202@egenix.com>	
	<50862ebd0507090604290df5f6@mail.gmail.com>	
	<ca471dc205070911216a57ff6e@mail.gmail.com>	
	<50862ebd05071106553fba99cb@mail.gmail.com>	
	<42D28242.4060306@egenix.com>	
	<50862ebd05071123533d2323bb@mail.gmail.com>	
	<42D3813A.5030208@egenix.com>
	<50862ebd05071217571163f3c0@mail.gmail.com>
Message-ID: <42D646CE.2060007@egenix.com>

Hi Neil,

>>>   With the proposed modification, sys.argv[1] u'\u20ac.txt' is
>>>converted through cp1251
>>
>>Actually, it is not: if you pass in a Unicode argument to
>>one of the file I/O functions and the OS supports Unicode
>>directly or at least provides the notion of a file system
>>encoding, then the file I/O should use the Unicode APIs
>>of the OS or convert the Unicode argument to the file system
>>encoding. AFAIK, this is how posixmodule.c already works
>>(more or less).
> 
> 
>    Yes it is. The initial stage is reading the command line arguments.
> The proposed modification is to change behaviour when constructing
> sys.argv, os.environ or when calling os.listdir to "Return unicode
> when the text can not be represented in Python's default encoding". I
> take this to mean that when the value can be represented in Python's
> default encoding then it is returned as a byte string in the default
> encoding.
> 
>    Therefore, for the example, the code that sets up sys.argv has to
> encode the unicode command line argument into cp1251.

Ok, I missed your point about sys.argv *not* returning Unicode
in this particular case.

However, with the modification of having posixmodule
and fileobject recode string input via Unicode (based on the
default encoding) into the file system encoding by basically
just changing the parser marker from "et" to "es", you
get correct behaviour - even in the above case.

Both posixmodule and fileobject would then take the cp1251
default encoded string, convert it to Unicode and then
to the file system encoding before opening the file.

>>On input, file I/O APIs should accept both strings using
>>the default encoding and Unicode. How these inputs are then
>>converted to suit the OS is up to the OS abstraction layer, e.g.
>>posixmodule.c.
> 
> 
>    This looks to me to be insufficiently compatible with current
> behaviour whih accepts byte strings outside the default encoding.
> Existing code may call open("?.txt"). This is perfectly legitimate
> current Python (with a coding declaration) as "?.txt" is a byte string
> and file systems will accept byte string names. Since the standard
> default encoding is ASCII, should such code raise UnicodeDecodeError?

Yes.

The above proposed change is indeed more restrictive than
the current pass-through approach. I'm not sure whether we
can impose such a change on the users in the 2.x series...
perhaps we should have a two phase approach:

Phase 1:
   try "et" and if this fails with an UnicodeDecodeError,
   revert back to the old "es" pass-through approach, issuing
   a warning as non-disruptive signal to the user

Phase 2:
   move to "et" for good and issue decode errors

>>Changing this is easy, though: instead of using the "et"
>>getargs format specifier, you'd have to use "es". The latter
>>recodes strings based on the default encoding assumption to
>>whatever other encoding you specify.
> 
>    Don't you want to convert these into unicode rather than another
> byte string encoding? It looks to me as though the "es" format always
> produces byte strings and the only byte string format that can be
> passed to the operating system is the file system encoding which may
> not contain all the characters in the default encoding.

If the OS support Unicode directly, we can (and do) have a
special case that bypasses the recoding altogheter. However,
this currently only appears to be available on Windows
versions NT, XP and up, where we already support this.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 14 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From aahz at pythoncraft.com  Thu Jul 14 13:27:57 2005
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 14 Jul 2005 04:27:57 -0700
Subject: [Python-Dev]  e-mail addresses
In-Reply-To: <42D61A16.4050602@egenix.com>
References: <db51n0$s1t$1@sea.gmane.org> <42D61A16.4050602@egenix.com>
Message-ID: <20050714112757.GB6540@panix.com>

On Thu, Jul 14, 2005, M.-A. Lemburg wrote:
>
> PS: Please don't use "-nospam" or the like email addresses when posting
> to this list. Thanks.

...unless it's a valid address.  Some people do use real addresses with
"nospam" as an actual part of the address as an anti-spam measure.  But
it's always polite to include "yes, this is a real address" or similar in
the .sig.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

From skip at pobox.com  Thu Jul 14 20:17:59 2005
From: skip at pobox.com (Skip Montanaro)
Date: Thu, 14 Jul 2005 13:17:59 -0500
Subject: [Python-Dev] [Python-checkins] python/dist/src/Misc
	developers.txt, 1.15, 1.16
In-Reply-To: <E1Dt7b1-0007Gx-K7@sc8-pr-cvs1.sourceforge.net>
References: <E1Dt7b1-0007Gx-K7@sc8-pr-cvs1.sourceforge.net>
Message-ID: <17110.44119.967994.231459@montanaro.dyndns.org>


    raymond> Log Message:
    raymond> Brett requests that Flovis's permissions be dropped.

Not to put too fine a spin on things, but I think it was more like Brett got
tired of waiting for Flovis's permissions to be increased and retracted his
original request.

Skip

From python at rcn.com  Thu Jul 14 20:33:58 2005
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 14 Jul 2005 14:33:58 -0400
Subject: [Python-Dev] [Python-checkins]
	python/dist/src/Miscdevelopers.txt, 1.15, 1.16
In-Reply-To: <17110.44119.967994.231459@montanaro.dyndns.org>
Message-ID: <002901c588a2$99a90e80$f9ba9d8d@oemcomputer>

>     raymond> Log Message:
>     raymond> Brett requests that Flovis's permissions be dropped.

[Skip]
> Not to put too fine a spin on things, but I think it was more like
Brett
> got
> tired of waiting for Flovis's permissions to be increased and
retracted
> his
> original request.


Brett and Flovis DID send a private email with a drop request this
morning.  They have chosen an alternate method of access.

Brett's original request was fulfilled within 48 hours.  I sent him a
confirmation note.  Also, there was a concurrent check-in notification
for Misc/developers.txt.  Additionally, Flovis's id appeared on the SF
developer list immediately.  If for some reason they did not see any of
those three, they could have sent a follow-up note and gotten a fourth
confirmation that the job was done.

IOW, the check-in message is accurate.  Your re-interpretation
notwithstanding, if there's a problem, it is not on this end.



Raymond

From bcannon at gmail.com  Thu Jul 14 20:52:59 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 14 Jul 2005 11:52:59 -0700
Subject: [Python-Dev] [Python-checkins]
	python/dist/src/Miscdevelopers.txt, 1.15, 1.16
In-Reply-To: <002901c588a2$99a90e80$f9ba9d8d@oemcomputer>
References: <17110.44119.967994.231459@montanaro.dyndns.org>
	<002901c588a2$99a90e80$f9ba9d8d@oemcomputer>
Message-ID: <bbaeab1005071411524dd7a43a@mail.gmail.com>

On 7/14/05, Raymond Hettinger <python at rcn.com> wrote:
> >     raymond> Log Message:
> >     raymond> Brett requests that Flovis's permissions be dropped.
> 
> [Skip]
> > Not to put too fine a spin on things, but I think it was more like
> Brett
> > got
> > tired of waiting for Flovis's permissions to be increased and
> retracted
> > his
> > original request.
> 
> 
> Brett and Flovis DID send a private email with a drop request this
> morning.  They have chosen an alternate method of access.
> 
> Brett's original request was fulfilled within 48 hours.  I sent him a
> confirmation note.  Also, there was a concurrent check-in notification
> for Misc/developers.txt.  Additionally, Flovis's id appeared on the SF
> developer list immediately.  If for some reason they did not see any of
> those three, they could have sent a follow-up note and gotten a fourth
> confirmation that the job was done.
>

Yeah, I missed all three; I just kept expecting a reply to the
python-dev list and wasn't looking for any other signs, so it's my
bad.  I moved over to Gmail a few weeks ago and I am still working out
my Python workflow with it.

-Brett

From mal at egenix.com  Thu Jul 14 21:15:28 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 14 Jul 2005 21:15:28 +0200
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42CF1DB5.6090602@gmail.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	<42C75006.6090902@ronadam.com>	<42C7E146.4090403@gmail.com>	<42C91A07.9030402@gmail.com>	<42CBBC92.4040804@gmail.com>	<42CEF42E.9040204@egenix.com>
	<42CF1DB5.6090602@gmail.com>
Message-ID: <42D6B9D0.1010309@egenix.com>

Nick Coghlan wrote:
> M.-A. Lemburg wrote:
> 
>>May I suggest that you use a different name than "context" for
>>this ?!
>>
>>The term "context" is way to broad for the application scopes
>>that you have in mind here (like e.g. managing a resource
>>in a multi-threaded application).
> 
> 
> It's actually the broadness of the term 'context' which is appealing - the 
> examples in the draft documentation on SF are:
> 
>    - resource management (synchronisation locks, generic 'closing')
>    - HTML tag matching
>    - Decimal arithmetic context
> 
> Any earlier version used 'suite managers' (partly to avoid confusing the hell 
> out of anyone ever exposed to Ruby's concept of blocks), but the 'context 
> management' term seems to more clearly describe what the protocol is for.

This is exactly what I'm getting at: I can see the potential
use for resource management (which is what started out the
whole idea IIRC), but fail to see why you'd want to use it
for anything more complicated than that.

Once you start talking about contexts (which usually refers
to a combination of environment, state and location) you
have to explain things like nesting, scopes, combination
of different contexts, their interaction with each other,
etc. etc.

Note that hiding things away in smart objects like what
you call "context managers" will not make programs easier
to understand, unless the specific task that such a "context
manager" is simple enough to grasp by just looking at its
definition in the with statement... but then you'd not call
it a "context manager".

BTW, the same argument applies to decorators. Programs don't
get easier to read or understand if you overload a function
with lots and lots of hidden magic...

@put_all_the_smart_stuff_here
def program(context):
    return "42"

Of course, you *could* do all these things and Python is
not preventing you from doing so, but will life get easier ?
I doubt it.

Let's keep things simple and Python nice.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 14 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From oliphant at ee.byu.edu  Thu Jul 14 22:25:20 2005
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 14 Jul 2005 14:25:20 -0600
Subject: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and
	Integers
In-Reply-To: <Pine.LNX.4.63.0506190029250.12171@leviathan.kdart.com>
References: <000301c5738b$6afc5fa0$bb07a044@oemcomputer>	<ca471dc20506171533147714a8@mail.gmail.com>	<42B3E41A.2020608@kdart.com>
	<2m1x6z7qu6.fsf@starship.python.net>
	<Pine.LNX.4.63.0506190029250.12171@leviathan.kdart.com>
Message-ID: <42D6CA30.7040607@ee.byu.edu>

Keith Dart wrote:

>On Sat, 18 Jun 2005, Michael Hudson wrote:
>
>  
>
>>The shortest way I know of going from 2149871625L to -2145095671 is
>>the still-fairly-gross:
>>
>>    
>>
>>>>>v = 2149871625L
>>>>>~int(~v&0xFFFFFFFF)
>>>>>          
>>>>>
>>-2145095671
>>
>>    
>>
>>>I suppose the best thing is to introduce an "unsignedint" type for this
>>>purpose.
>>>      
>>>
>>Or some kind of bitfield type, maybe.
>>
>>C uses integers both as bitfields and to count things, and at least in
>>my opinion the default assumption in Python should be that this is
>>what an integer is being used for, but when you need a bitfield it can
>>all get a bit horrible.
>>
>>That said, I think in this case we can just make fcntl_ioctl use the
>>(new-ish) 'I' format argument to PyArg_ParseTuple and then you'll just
>>be able to use 2149871625L and be happy (I think, haven't tried this).
>>    
>>
>
>Thanks for the reply. I think I will go ahead and add some extension types 
>to Python. Thankfully, Python is extensible with new objects.
>
>It is also useful (to me, anyway) to be able to map, one to one,
>external primitives from other systems to Python primitives. For
>example, CORBA and SNMP have a set of types (signed ints, unsigned ints,
>etc.) defined that I would like to interface to Python (actually I have
>already done this to some degree). But Python makes it a bit more
>difficult without that one-to-one mapping of basic types.  Having an
>unsigned int type, for example, would make it easier to interface Python
>to SNMP or even some C libraries.
>
>In other words, Since the "Real World" has these types that I must
>sometimes interface to, it is useful to have these same (predictable)
>types in Python.
>
>So, it is worth extending the basic set of data types, and I will add it
>to my existing collection of Python extensions.
>
>Therefore, I would like to ask here if anyone has already started
>something like this? If not, I will go ahead and do it (if I have time).
>
>  
>

I should make you aware that the new Numeric (Numeric3 now called 
scipy.base) has a collection of C-types that represent each 
C-datatype.   They are (arguably) useful in the context of eliminating a 
few problems in data-type coercion in scientific computing. 

These types are created in C and use multiple inheritance in C.  This is 
very similiar to what you are proposing and so I thought I might make 
you aware.  Right now, the math operations from each of these types 
comes mostly from Numeric but this could be modified as desired. 

The code is available in the Numeric3 CVS tree at the numeric python 
sourceforge site.


-Travis Oliphant




From reinhold-birkenfeld-nospam at wolke7.net  Thu Jul 14 22:46:53 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Thu, 14 Jul 2005 22:46:53 +0200
Subject: [Python-Dev] Python on PyPI
Message-ID: <db6ivu$ise$1@sea.gmane.org>

Hi,

to whom it may concern:
the Python package on PyPI is at version 2.3.2.

Reinhold

-- 
Mail address is perfectly valid!


From raymond.hettinger at verizon.net  Thu Jul 14 22:54:56 2005
From: raymond.hettinger at verizon.net (Raymond Hettinger)
Date: Thu, 14 Jul 2005 16:54:56 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42D6B9D0.1010309@egenix.com>
Message-ID: <003901c588b6$4abdb820$f9ba9d8d@oemcomputer>

{MAL]
> This is exactly what I'm getting at: I can see the potential
> use for resource management (which is what started out the
> whole idea IIRC), but fail to see why you'd want to use it
> for anything more complicated than that.

Substitute "different" for "complicated".

'with' is not application specific, it is incredibly general.  All it
does is abstract recurring uses of try/finally.

Naming it after a specific class of applications would be a mistake.


Raymond


From martin at v.loewis.de  Fri Jul 15 07:30:35 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 15 Jul 2005 07:30:35 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE
	for	review)
In-Reply-To: <ca471dc205070400441ab49ffb@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>	<5.1.1.6.0.20050626204633.02102cc8@mail.telecommunity.com>	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>	<d9p4fk$kvd$1@sea.gmane.org>	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>	<ca471dc20506272343cbe7614@mail.gmail.com>	<50862ebd05063016466f3e6abd@mail.gmail.com>	<ca471dc2050703112845321ad3@mail.gmail.com>	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
Message-ID: <42D749FB.6040506@v.loewis.de>

Guido van Rossum wrote:
> Ah, sigh. I didn't know that os.listdir() behaves differently when the
> argument is Unicode. Does os.listdir(".") really behave differently
> than os.listdir(u".")? Bah! I don't think that's a very good design
> (although I see where it comes from). Promoting only those entries
> that need it seems the right solution

Unfortunately, this solution is hard to implement (I don't know whether
it is implementable at all correctly; atleast on Windows, I see no
way to implement it efficiently).

Here are a number of problems/questions:
- On Windows, should listdir use the narrow or the wide API? Obviously
  the wide API, since it is not Python which returns the question marks,
  but the Windows API.
- But then, the wide API gives all results as Unicode. If you want to
  promote only those entries that need it, it really means that you
  only want to "demote" those that don't need it. But how can you tell
  whether an entry needs it? There is no API to find out.
  You could declare that anything with characters >128 needs it,
  but that would be an incompatible change: If a character >128 in
  the system code page is in a file name, listdir currently returns
  it in the system code page. It then would return a Unicode string.
  Applications relying on the olde behaviour would break.
- On Unix, all file names come out as byte strings. Again, how do
  you know which ones to promote, and using what encoding? Python
  currently guesses an encoding, but that may or may not be the one
  intended for the file name.

So the general "Bah!" doesn't really help much: when it comes to
a specific algorithm to implement, the options are scarce.

Regards,
Martin

From mwh at python.net  Fri Jul 15 11:37:10 2005
From: mwh at python.net (Michael Hudson)
Date: Fri, 15 Jul 2005 10:37:10 +0100
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42D6B9D0.1010309@egenix.com> (M.'s message of "Thu, 14 Jul
	2005 21:15:28 +0200")
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>
	<42C91A07.9030402@gmail.com> <42CBBC92.4040804@gmail.com>
	<42CEF42E.9040204@egenix.com> <42CF1DB5.6090602@gmail.com>
	<42D6B9D0.1010309@egenix.com>
Message-ID: <2mslyg2ywp.fsf@starship.python.net>

"M.-A. Lemburg" <mal at egenix.com> writes:

> This is exactly what I'm getting at: I can see the potential
> use for resource management (which is what started out the
> whole idea IIRC), but fail to see why you'd want to use it
> for anything more complicated than that.

I, as a concrete example, want to be able to write:

with output_to_file(f):
    print stuff
    function_that_prints_stuff()

and have the printed things end up in the file-like object f (in a
single-threaded program, foom :)

This is only a resource by a tortured defintion.

> Note that hiding things away in smart objects like what you call
> "context managers" will not make programs easier to understand,
> unless the specific task that such a "context manager" is simple
> enough to grasp by just looking at its definition in the with
> statement... but then you'd not call it a "context manager".

Of course, but there's no single term to describe all these simple
things, and we need a single term to describe the objects designed to
be used in the with statement for documentation purposes.  Consensus
on python-dev has settled on 'context manager', but personally I don't
much care what it is so long as it isn't actively misleading (which I
contend applies to 'resource manager'), it's just something people can
look up in the index.

> Let's keep things simple and Python nice.

Are you arguing against PEP 343 as a whole, here?

Cheers,
mwh

-- 
  CLiki pages can be edited by anybody at any time. Imagine the most
  fearsomely comprehensive legal disclaimer you have ever seen, and
  double it                        -- http://ww.telent.net/cliki/index

From mal at egenix.com  Fri Jul 15 11:45:53 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 15 Jul 2005 11:45:53 +0200
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <003901c588b6$4abdb820$f9ba9d8d@oemcomputer>
References: <003901c588b6$4abdb820$f9ba9d8d@oemcomputer>
Message-ID: <42D785D1.10404@egenix.com>

Raymond Hettinger wrote:
> {MAL]
> 
>>This is exactly what I'm getting at: I can see the potential
>>use for resource management (which is what started out the
>>whole idea IIRC), but fail to see why you'd want to use it
>>for anything more complicated than that.
> 
> 
> Substitute "different" for "complicated".
> 
> 'with' is not application specific, it is incredibly general.  All it
> does is abstract recurring uses of try/finally.
> 
> Naming it after a specific class of applications would be a mistake.

Exactly. Which is why "context manager" is IMHO the wrong description.

Calling it "block object" or "with object" or even "try-finally object"
would be more in line with the PEP without causing associations which
might lead to misunderstandings.

Please remember that you have to explain all these things to new
Python users. Over the last few years there have been tons of
new additions to the language - while some will probably disagree,
the learning curve for novices has gotten a lot steeper compared
to the pre-2.0 days when there was much resistance to adding new
features.

Nowadays, for a new programmer to get up and running
with the language and to start working on existing code, you have
to teach them about generators, iterators, decorators, the with
statement - since programs are starting to use these features
actively. More and more program logic gets hidden by the way of
introducing new objects and protocols.

If you then start using terms in the documentation that cause
wrong associations, you make life harder for new programmers.

Anyway, I think I've made my point.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 15 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From mal at egenix.com  Fri Jul 15 12:21:17 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 15 Jul 2005 12:21:17 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some
	RFE	for	review)
In-Reply-To: <42D749FB.6040506@v.loewis.de>
References: <d9mmd6$gjf$1@sea.gmane.org>	<5.1.1.6.0.20050626204633.02102cc8@mail.telecommunity.com>	<Pine.LNX.4.62.0506270814540.19016@qnzvnan.rov.np.hx>	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>	<d9p4fk$kvd$1@sea.gmane.org>	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>	<ca471dc20506272343cbe7614@mail.gmail.com>	<50862ebd05063016466f3e6abd@mail.gmail.com>	<ca471dc2050703112845321ad3@mail.gmail.com>	<50862ebd05070317183d971bef@mail.gmail.com>	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<42D749FB.6040506@v.loewis.de>
Message-ID: <42D78E1D.4070705@egenix.com>

Martin v. L?wis wrote:
> Guido van Rossum wrote:
> 
>>Ah, sigh. I didn't know that os.listdir() behaves differently when the
>>argument is Unicode. Does os.listdir(".") really behave differently
>>than os.listdir(u".")? Bah! I don't think that's a very good design
>>(although I see where it comes from). Promoting only those entries
>>that need it seems the right solution
> 
> 
> Unfortunately, this solution is hard to implement (I don't know whether
> it is implementable at all correctly; atleast on Windows, I see no
> way to implement it efficiently).
> 
> Here are a number of problems/questions:
> - On Windows, should listdir use the narrow or the wide API? Obviously
>   the wide API, since it is not Python which returns the question marks,
>   but the Windows API.

Right.

> - But then, the wide API gives all results as Unicode. If you want to
>   promote only those entries that need it, it really means that you
>   only want to "demote" those that don't need it. But how can you tell
>   whether an entry needs it? There is no API to find out.
>   You could declare that anything with characters >128 needs it,
>   but that would be an incompatible change: If a character >128 in
>   the system code page is in a file name, listdir currently returns
>   it in the system code page. It then would return a Unicode string.
>   Applications relying on the olde behaviour would break.

We will need a Python C API that returns:

* a string if the Unicode value is representable in the
  default encoding (usually ASCII)

* Unicode if it is not

The file system encoding should be hidden in the OS
layer (e.g. posixmodule). Python should only return
strings with the default encoding and Unicode
otherwise.

See my suggestion to Neil about making the transition to
this new strategy less painful.

> - On Unix, all file names come out as byte strings. Again, how do
>   you know which ones to promote, and using what encoding? Python
>   currently guesses an encoding, but that may or may not be the one
>   intended for the file name.

This is a tough one: AFAIK the file system encoding in Unix
was never really specified, in fact most file systems just
stored the names as-is without any encoding information attached
to it.

Things are moving into the direction of using UTF-8 for
filenames, though.

To solve this issue, various applications have come up with
ways around the problem, e.g. GTK uses the following strategy
to find the encoding (in the given order and adjustable using
an environment  variable):

1. locale based encoding, if given (UTF-8 on most modern Unixes)
2. UTF-8
3. Latin-1
4. CP1252 (Windows Latin-1 version)

Perhaps we should add similar support to Python ?

We should probably use a file system encoding default
of Latin-1 on Unix if no other information can be found.

That way we will assure that things don't change on
Unix unless explicitly setup by the user (Latin-1 is
round-trip safe when converting it to Unicode and back).

os.listdir() would then continue to return plain strings
and file() will open them just it does now.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 15 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From ncoghlan at gmail.com  Fri Jul 15 12:47:59 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 15 Jul 2005 20:47:59 +1000
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42D6B9D0.1010309@egenix.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	<42C75006.6090902@ronadam.com>	<42C7E146.4090403@gmail.com>	<42C91A07.9030402@gmail.com>	<42CBBC92.4040804@gmail.com>	<42CEF42E.9040204@egenix.com>
	<42CF1DB5.6090602@gmail.com> <42D6B9D0.1010309@egenix.com>
Message-ID: <42D7945F.7040301@gmail.com>

M.-A. Lemburg wrote:
> This is exactly what I'm getting at: I can see the potential
> use for resource management (which is what started out the
> whole idea IIRC), but fail to see why you'd want to use it
> for anything more complicated than that.

The other suggested uses (redirecting stdout, logging exceptions, inserting 
fences in markup, switching decimal context) aren't really more complicated. 
They're just different cases of 'paired code' - code which consists of 
'standard setup code', 'the unique bit', 'standard cleanup code'.

The longest example context manager in PEP 343 is only 11 lines long. Even the 
wrapper to turn a generator into a context manager weighs in at only 23 lines.

> Once you start talking about contexts (which usually refers
> to a combination of environment, state and location) you
> have to explain things like nesting, scopes, combination
> of different contexts, their interaction with each other,
> etc. etc.

Except that context managers combine contexts in a very simple way - each one 
is almost entirely independent of both its surroundings and its contents. Each 
context manager takes a specific action to set the context up, and a specific 
action to tear it down again afterwards. Its behaviour is dependent only on 
the arguments that are passed to its constructor, and exceptions raised by its 
contents.

The only way to make a context manager depend on its position in the code 
(rather than the passed in arguments) is to use sys._getframe, and using that 
is always considered an evil hack :)

> Note that hiding things away in smart objects like what
> you call "context managers" will not make programs easier
> to understand, unless the specific task that such a "context
> manager" is simple enough to grasp by just looking at its
> definition in the with statement... but then you'd not call
> it a "context manager".

Each one on its own may not be called a context manager, but we still need a 
collective term that covers all of the simple (but different) cases of common 
setup and cleanup code that we would like to factor out.

We tried 'resource managers' (which was too specific to one particular use 
case), 'block managers' (a bit too close to the related-but-very-different 
Ruby blocks) and 'suite managers' (which wasn't too bad, but not very 
intuitive) along the way, but 'context managers' was the first one that really 
seemed to adequately summarise the nature of the protocol - allowing a 
programmer to factor out arbitrary setup and cleanup code that would otherwise 
have to be reproduced inline everywhere they needed it.

> BTW, the same argument applies to decorators. Programs don't
> get easier to read or understand if you overload a function
> with lots and lots of hidden magic...

No argument here, but notice that the generic term 'decorator' tells you 
nothing about what any *specific* decorator does. The obviousness needs to be 
in the name of the decorator (such as 'classmethod'). The situation is the 
same for context managers - to make the code easy to read, the method or 
variable used to denote the context manager in the with statement must be well 
named.

> @put_all_the_smart_stuff_here
> def program(context):
>     return "42"
> 
> Of course, you *could* do all these things and Python is
> not preventing you from doing so, but will life get easier ?
> I doubt it.

But what about:

   for item in put_all_the_smart_stuff_here():
       item.value = 42

The other guiding light in the terminology discussion was the existing concept 
of iterables and iterators. Those can do just about anything you want, and 
frequently hide a great deal of complexity. However, if they're well named, 
then it is possible to read a for loop that uses them without batting an eyelid.

If the reader decides they need to know the details, they look up the 
documentation of the iterator, just as they'd look up the details of a 
decorator they didn't recognise. Once they've looked up the definition once, 
instead of having to recognise a particular usage pattern in the code ("Oh, 
that's doing 'X' again"), the reader simply has to recognise the name ("Oh, 
that's the decorator/iterator/context manager that does 'X'")

> Let's keep things simple and Python nice.

Indeed - but I see being able to factor out common code as both simple *and* 
nice, which is why I like the ideas of functions, iterators, decorators and 
context managers :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From ncoghlan at gmail.com  Fri Jul 15 13:19:53 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 15 Jul 2005 21:19:53 +1000
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42D785D1.10404@egenix.com>
References: <003901c588b6$4abdb820$f9ba9d8d@oemcomputer>
	<42D785D1.10404@egenix.com>
Message-ID: <42D79BD9.9010105@gmail.com>

M.-A. Lemburg wrote:
> If you then start using terms in the documentation that cause
> wrong associations, you make life harder for new programmers.

I agree that every new construct and protocol makes life that much harder for 
anyone learning Python, but the bit I'm having trouble grasping is why you 
think associating 'with' statements with the term 'context' is *wrong*.

The point of using that term in the documentation was to give people something 
to grab hold of that defines what the protocol is *for*, rather than dropping 
something completely abstract like "the 'with' protocol" on them.

What does a 'with object' do? Nothing obvious, and this poses a major problem 
when trying to write the associated documentation. For instance, what's the 
justification for the use of __enter__ and __exit__ as the method names?

OTOH, what does a 'context manager' do? It sets up and tears down a particular 
context as a section of code is entered and exited. Simple, succint, accurate, 
and provides a rationale for the method names used in the protocol.

There's clearly something that bothers you about this though, and I'd like to 
understand what it is. Does the term 'context' carry additional, more 
specific, connotations for you that I'm simply not taking into account?

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From jimjjewett at gmail.com  Fri Jul 15 18:45:36 2005
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 15 Jul 2005 12:45:36 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
Message-ID: <fb6fbf5605071509458933c17@mail.gmail.com>

Nick Coghlan asked Marc-Andre Lemburg:

> There's clearly something that bothers you about this though, and I'd like to 
> understand what it is. Does the term 'context' carry additional, more 
> specific, connotations for you that I'm simply not taking into account?

To me, a context is much larger than a single object.

That said, I can't think of any better words.  It *might* be worth 
noting that context managers don't have to control the entire 
context -- they will often affect only one small facet, and it is
OK to nest them if you want to control more than that.

-jJ

From rrr at ronadam.com  Fri Jul 15 21:55:44 2005
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 15 Jul 2005 15:55:44 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <2mslyg2ywp.fsf@starship.python.net>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	<42C75006.6090902@ronadam.com>
	<42C7E146.4090403@gmail.com>	<42C91A07.9030402@gmail.com>
	<42CBBC92.4040804@gmail.com>	<42CEF42E.9040204@egenix.com>
	<42CF1DB5.6090602@gmail.com>	<42D6B9D0.1010309@egenix.com>
	<2mslyg2ywp.fsf@starship.python.net>
Message-ID: <42D814C0.3020703@ronadam.com>

Michael Hudson wrote:
> "M.-A. Lemburg" <mal at egenix.com> writes:
> 
> 
>>This is exactly what I'm getting at: I can see the potential
>>use for resource management (which is what started out the
>>whole idea IIRC), but fail to see why you'd want to use it
>>for anything more complicated than that.
> 
> 
> I, as a concrete example, want to be able to write:
> 
> with output_to_file(f):
>     print stuff
>     function_that_prints_stuff()
> 
> and have the printed things end up in the file-like object f (in a
> single-threaded program, foom :)

I would like it to be that easy also.  However, it seems to me that 
using a context manager within try-except blocks will be a very common 
practice.

     try:
        with some_context() as var:
            <do stuff>
     except:
        <flag, log, and/or handle error>
     else:
        <everything is ok>

The context manager will handle it's own cleanup, but we will still (in 
most cases) need to react to the raised exception somehow (and 
someplace) even if it's with a pass.

It makes me think that the 'with' would be better expressed as a 
variation of a try statement.  And the documentation for the 'with' 
statement would then be grouped and explained along with the try statements.

Possibly:

     try with some_context() as VAR:
         <do stuff with VAR>
     except:                             # optional except-else?
         <react to error in context>
     else:
         <good to go>


or just:

     trywith some_context() as VAR:      # May cause an exception
         <do stuff with VAR>             # that needs to be caught.


I guess my point is: Since it's an encapsulated try-finally with a 
definite chance of generating an exception, Having a stronger 
association to 'try' in both the syntax and the documentation may be good.

Cheers,
Ron


From gvanrossum at gmail.com  Fri Jul 15 22:05:53 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Fri, 15 Jul 2005 13:05:53 -0700
Subject: [Python-Dev] 'With' context documentation draft (was Re:
	Terminology for PEP 343
In-Reply-To: <42D814C0.3020703@ronadam.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>
	<42C91A07.9030402@gmail.com> <42CBBC92.4040804@gmail.com>
	<42CEF42E.9040204@egenix.com> <42CF1DB5.6090602@gmail.com>
	<42D6B9D0.1010309@egenix.com> <2mslyg2ywp.fsf@starship.python.net>
	<42D814C0.3020703@ronadam.com>
Message-ID: <ca471dc205071513054c944117@mail.gmail.com>

On 7/15/05, Ron Adam <rrr at ronadam.com> wrote:
[several new syntax proposals]

Please stop proposing new syntax. The PEP was accepted after quite
enough back-and-forth; there's no point opening this up yet again.

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

From rrr at ronadam.com  Sat Jul 16 00:09:24 2005
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 15 Jul 2005 18:09:24 -0400
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <ca471dc205071513054c944117@mail.gmail.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>	
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>	
	<42C91A07.9030402@gmail.com> <42CBBC92.4040804@gmail.com>	
	<42CEF42E.9040204@egenix.com> <42CF1DB5.6090602@gmail.com>	
	<42D6B9D0.1010309@egenix.com> <2mslyg2ywp.fsf@starship.python.net>	
	<42D814C0.3020703@ronadam.com>
	<ca471dc205071513054c944117@mail.gmail.com>
Message-ID: <42D83414.7030200@ronadam.com>

Guido van Rossum wrote:
> On 7/15/05, Ron Adam <rrr at ronadam.com> wrote:
> [several new syntax proposals]
> 
> Please stop proposing new syntax. The PEP was accepted after quite
> enough back-and-forth; there's no point opening this up yet again.

My apologies Guido.


Subtracting the inappropriate syntax suggestions leaves the following 
hopefully on-topic documentation suggestions.


It may be good to have a stronger association to "try" in the 
documentation by:

     1. Suggesting to the programmer that in many situations a with can 
be thought of as 'try with'.

     2. Reminding or clarify that a with will handle the object or 
context cleanup, but the programmer *may still* need to catch exceptions 
that are generated within the block with a "try-except" at some point.

     3. The "with" documentation could possibly be grouped with or after 
the "try" documentation as it may be easier to understand in that context.


Regards,
Ron

From ncoghlan at gmail.com  Sat Jul 16 00:36:47 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 16 Jul 2005 08:36:47 +1000
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42D83414.7030200@ronadam.com>
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>		<42C75006.6090902@ronadam.com>
	<42C7E146.4090403@gmail.com>		<42C91A07.9030402@gmail.com>
	<42CBBC92.4040804@gmail.com>		<42CEF42E.9040204@egenix.com>
	<42CF1DB5.6090602@gmail.com>		<42D6B9D0.1010309@egenix.com>
	<2mslyg2ywp.fsf@starship.python.net>		<42D814C0.3020703@ronadam.com>	<ca471dc205071513054c944117@mail.gmail.com>
	<42D83414.7030200@ronadam.com>
Message-ID: <42D83A7F.9010300@gmail.com>

Ron Adam wrote:
>      3. The "with" documentation could possibly be grouped with or after 
> the "try" documentation as it may be easier to understand in that context.

I was looking for an appropriate place in the tutorial to put a couple of 
usage examples - a new subsection immediately after the introduction of 
try/finally (8.7, IIRC) seemed to make the most sense.

However, I figured that bit could wait until I had a chance to play with an 
actual implementation.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From stephen at xemacs.org  Sat Jul 16 07:58:03 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 16 Jul 2005 14:58:03 +0900
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <fb6fbf5605071509458933c17@mail.gmail.com> (Jim Jewett's
	message of "Fri, 15 Jul 2005 12:45:36 -0400")
References: <fb6fbf5605071509458933c17@mail.gmail.com>
Message-ID: <87zmsns36c.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Jim" == Jim Jewett <jimjjewett at gmail.com> writes:

    Jim> Nick Coghlan asked Marc-Andre Lemburg:

    >> There's clearly something that bothers you about this though,
    >> and I'd like to understand what it is. Does the term 'context'
    >> carry additional, more specific, connotations for you that I'm
    >> simply not taking into account?

    Jim> To me, a context is much larger than a single object.

To me, "*the* context" can be as small as exactly the subset of the
environment that you need to manage to ensure correct behavior of the
object(s) being managed.  Eg, in quoting in email "preserving context"
does not require quoting the whole message referenced in most cases.
You only need to quote enough to ensure that the author's intention is
conveyed to your readers.

However, a "context manager" need not manage the whole context of the
calling module, only those parts the encapsulated code might damage or
misinterpret.  Continuing with the email quoting example, if I then go
on to quote a different part of the same email you did, I don't (in
general) have to preserve the context that you did, only that of the
part that I quote.

I don't know that that should be convincing to those who have other
associations for the word "context", but maybe it's a useful mnemonic
and analogy for tutorial writers.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From nyamatongwe at gmail.com  Sat Jul 16 09:30:07 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sat, 16 Jul 2005 17:30:07 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <42D749FB.6040506@v.loewis.de>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>
	<d9p4fk$kvd$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
	<ca471dc2050703112845321ad3@mail.gmail.com>
	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<42D749FB.6040506@v.loewis.de>
Message-ID: <50862ebd05071600305f162f38@mail.gmail.com>

Martin v. L?wis:

> - But then, the wide API gives all results as Unicode. If you want to
>   promote only those entries that need it, it really means that you
>   only want to "demote" those that don't need it. But how can you tell
>   whether an entry needs it? There is no API to find out.

   I wrote a patch for os.listdir at
http://www.scintilla.org/difft.txt that uses WideCharToMultiByte to
check if a wide name can be represented in a particular code page and
only uses that representation if it fits. This is good for Windows
code pages including ASCII and "mbcs" but since Python's
sys.getdefaultencoding() can be something that has no code page
equivalent, it would have to try converting using strict mode and
interpret failure as leaving the name as unicode.

>   You could declare that anything with characters >128 needs it,
>   but that would be an incompatible change: If a character >128 in
>   the system code page is in a file name, listdir currently returns
>   it in the system code page. It then would return a Unicode string.

   I now quite like returning unicode for anything non-ASCII on
Windows as there is no ambiguity in what the result means and there
will be no need to change all the system calls to translate from the
default encoding. It is a change to the API which can lead to code
breaking but it should break with an exception. Assuming that byte
string arguments are using Python's default encoding looks more
dangerous with a behavioural change but no notification.

   Neil

From cludwig at cdc.informatik.tu-darmstadt.de  Sat Jul 16 12:13:58 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sat, 16 Jul 2005 12:13:58 +0200
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
In-Reply-To: <42D15DB2.3020300@v.loewis.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42CDA654.2080106@v.loewis.de>
	<uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D15DB2.3020300@v.loewis.de>
Message-ID: <20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>

On Sun, Jul 10, 2005 at 07:41:06PM +0200, "Martin v. L?wis" wrote:
> Christoph Ludwig wrote:
> > My point is: The test implemented in the 2.4.1 configure script gives a wrong
> > result if your platform happens to be x86 Linux with ELF binaries and 
> > g++ 4.0. 
[...]
> > But I digress. It's not that important for our discussion whether a C++
> > compiler must / should / is allowed to add exception handling code to the
> > call of an extern "C" function. The point is that some do *unless* they see
> > the function definition. I contend the test involving two TUs matches more
> > closely the situation with ccpython.cc than the current test.
> 
> Maybe. For Python 2.4, feel free to contribute a more complex test. For
> Python 2.5, I would prefer if the entire code around ccpython.cc was
> removed.

I submitted patch #1239112 that implements the test involving two TUs for
Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but
that will take some time.

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html


From reinhold-birkenfeld-nospam at wolke7.net  Sat Jul 16 18:34:46 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Sat, 16 Jul 2005 18:34:46 +0200
Subject: [Python-Dev] Some RFE for review
In-Reply-To: <d9mmd6$gjf$1@sea.gmane.org>
References: <d9mmd6$gjf$1@sea.gmane.org>
Message-ID: <dbbcv6$id4$1@sea.gmane.org>

Reinhold Birkenfeld wrote:
> Hi,
> 
> while bugs and patches are sometimes tricky to close, RFE can be very easy
> to decide whether to implement in the first place. So what about working a
> bit on this front? Here are several RFE reviewed, perhaps some can be
> closed ("should" is always from submitter's point of view):

Aren't there opinions to the RFE other than the "path module" one?

Reinhold

-- 
Mail address is perfectly valid!


From dave at boost-consulting.com  Sat Jul 16 21:02:50 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 16 Jul 2005 15:02:50 -0400
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
References: <u8y0jz762.fsf@boost-consulting.com>
	<42CDA654.2080106@v.loewis.de> <uu0j6p7z1.fsf@boost-consulting.com>
	<20050708072807.GC3581@lap200.cdc.informatik.tu-darmstadt.de>
	<u8y0hl45u.fsf@boost-consulting.com> <42CEF948.3010908@v.loewis.de>
	<20050709102010.GA3836@lap200.cdc.informatik.tu-darmstadt.de>
	<42D0D215.9000708@v.loewis.de>
	<20050710125458.GA3587@lap200.cdc.informatik.tu-darmstadt.de>
	<42D15DB2.3020300@v.loewis.de>
	<20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <ull46bmlh.fsf@boost-consulting.com>

Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:

> I submitted patch #1239112 that implements the test involving two TUs for
> Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but
> that will take some time.

Thanks very much for your efforts, Christoph!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


From anthony at interlink.com.au  Sun Jul 17 08:01:20 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sun, 17 Jul 2005 16:01:20 +1000
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
In-Reply-To: <20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com> <42D15DB2.3020300@v.loewis.de>
	<20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <200507171601.23780.anthony@interlink.com.au>

On Saturday 16 July 2005 20:13, Christoph Ludwig wrote:
> I submitted patch #1239112 that implements the test involving two TUs for
> Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but
> that will take some time.

I'm only vaguely aware of all of the issues here with linking, but if this
is to be considered for 2.4.2, it needs to be low risk of breaking anything.
2.4.2 is a bugfix release, and I'd hate to have this break other systems that 
work...

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

From martin at v.loewis.de  Sun Jul 17 09:41:12 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 17 Jul 2005 09:41:12 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <50862ebd05071600305f162f38@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>	
	<5.1.1.6.0.20050627110223.021064b8@mail.telecommunity.com>	
	<d9p4fk$kvd$1@sea.gmane.org>	
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>	
	<ca471dc20506272343cbe7614@mail.gmail.com>	
	<50862ebd05063016466f3e6abd@mail.gmail.com>	
	<ca471dc2050703112845321ad3@mail.gmail.com>	
	<50862ebd05070317183d971bef@mail.gmail.com>	
	<ca471dc205070400441ab49ffb@mail.gmail.com>	
	<42D749FB.6040506@v.loewis.de>
	<50862ebd05071600305f162f38@mail.gmail.com>
Message-ID: <42DA0B98.7020700@v.loewis.de>

Neil Hodgson wrote:
>>- But then, the wide API gives all results as Unicode. If you want to
>>  promote only those entries that need it, it really means that you
>>  only want to "demote" those that don't need it. But how can you tell
>>  whether an entry needs it? There is no API to find out.
> 
> 
>    I wrote a patch for os.listdir at
> http://www.scintilla.org/difft.txt that uses WideCharToMultiByte to
> check if a wide name can be represented in a particular code page and
> only uses that representation if it fits.

This appears to be based on the usedDefault return value of
WideCharToMultiByte. I believe this is insufficient:
WideCharToMultiByte might convert Unicode characters to
codepage characters in a lossy way, without using the default
character. For example, it converts U+0308 (combining diaeresis)
to U+00A8 (diaeresis) (or something like that, I forgot the
exact details). So if you have, say, "p-umlaut" (i.e. U+0070
U+0308), it converts it to U+0070 U+00A8 (in the local code page).
Trying to use this as a filename later fails.

Regards,
Martin

From nyamatongwe at gmail.com  Sun Jul 17 10:26:33 2005
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sun, 17 Jul 2005 18:26:33 +1000
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <42DA0B98.7020700@v.loewis.de>
References: <d9mmd6$gjf$1@sea.gmane.org>
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>
	<ca471dc20506272343cbe7614@mail.gmail.com>
	<50862ebd05063016466f3e6abd@mail.gmail.com>
	<ca471dc2050703112845321ad3@mail.gmail.com>
	<50862ebd05070317183d971bef@mail.gmail.com>
	<ca471dc205070400441ab49ffb@mail.gmail.com>
	<42D749FB.6040506@v.loewis.de>
	<50862ebd05071600305f162f38@mail.gmail.com>
	<42DA0B98.7020700@v.loewis.de>
Message-ID: <50862ebd050717012676126cbd@mail.gmail.com>

Martin v. L?wis:

> This appears to be based on the usedDefault return value of
> WideCharToMultiByte. I believe this is insufficient:
> WideCharToMultiByte might convert Unicode characters to
> codepage characters in a lossy way, without using the default
> character. For example, it converts U+0308 (combining diaeresis)
> to U+00A8 (diaeresis) (or something like that, I forgot the
> exact details). So if you have, say, "p-umlaut" (i.e. U+0070
> U+0308), it converts it to U+0070 U+00A8 (in the local code page).
> Trying to use this as a filename later fails.

   There is WC_NO_BEST_FIT_CHARS to defeat that. It says that it will
use the default character if the translation can't be round-tripped.
Available on WIndows 2000 and XP but not NT4. We could compare the
original against the round-tripped as described at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_2bj9.asp

   Neil

From cludwig at cdc.informatik.tu-darmstadt.de  Sun Jul 17 12:06:09 2005
From: cludwig at cdc.informatik.tu-darmstadt.de (Christoph Ludwig)
Date: Sun, 17 Jul 2005 12:06:09 +0200
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
In-Reply-To: <200507171601.23780.anthony@interlink.com.au>
References: <u8y0jz762.fsf@boost-consulting.com> <42D15DB2.3020300@v.loewis.de>
	<20050716101357.GC3607@lap200.cdc.informatik.tu-darmstadt.de>
	<200507171601.23780.anthony@interlink.com.au>
Message-ID: <20050717100609.GB3581@lap200.cdc.informatik.tu-darmstadt.de>

On Sun, Jul 17, 2005 at 04:01:20PM +1000, Anthony Baxter wrote:
> On Saturday 16 July 2005 20:13, Christoph Ludwig wrote:
> > I submitted patch #1239112 that implements the test involving two TUs for
> > Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but
> > that will take some time.
> 
> I'm only vaguely aware of all of the issues here with linking, but if this
> is to be considered for 2.4.2, it needs to be low risk of breaking anything.
> 2.4.2 is a bugfix release, and I'd hate to have this break other systems that 
> work...

I prepared the patch for 2.4.2 since it is indeed a bugfix. The current test
produces wrong results if the compiler is GCC 4.0 which inhibits a successful
build of Python 2.4.

I tested the patch with GCC 2.95, 3.3 and 4.0 - those are the only compilers I
have easy access to right now. I do not see how this patch could cause
regressions on other platforms because it mimics the situation
w.r.t. ccpython.cc: A C++ translation unit calls from main() an extern "C"
function in a separate C translation unit. The test determines whether it is
possible to produce an intact executable if the C compiler is used as linker
driver. If this test causes problems on some platform then you'd expect
trouble when linking the python executable out of ccpython.o and all the other
C object modules anyway.

But, of course, I might be wrong. I do not claim that I am familiar with every
platform's peculiarities. That's why the patch is up for review. I'd appreciate
if users on other platforms test it.

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html


From reinhold-birkenfeld-nospam at wolke7.net  Sun Jul 17 15:02:54 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Sun, 17 Jul 2005 15:02:54 +0200
Subject: [Python-Dev] python/dist/src/Doc/lib emailutil.tex,1.11,1.12
In-Reply-To: <E1Du7ca-0005NL-Ga@sc8-pr-cvs1.sourceforge.net>
References: <E1Du7ca-0005NL-Ga@sc8-pr-cvs1.sourceforge.net>
Message-ID: <dbdktu$ag2$1@sea.gmane.org>

montanaro at users.sourceforge.net wrote:
> Update of /cvsroot/python/python/dist/src/Doc/lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20654
> 
> Modified Files:
> 	emailutil.tex 
> Log Message:
> Note that usegmt is new in 2.4.  Closes #1239681.
> 
> 
> Index: emailutil.tex
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Doc/lib/emailutil.tex,v
> retrieving revision 1.11
> retrieving revision 1.12
> diff -u -d -r1.11 -r1.12
> --- emailutil.tex	1 Nov 2004 03:59:24 -0000	1.11
> +++ emailutil.tex	17 Jul 2005 11:47:46 -0000	1.12
> @@ -103,7 +103,8 @@
>  Optional \var{usegmt} is a flag that when \code{True}, outputs a 
>  date string with the timezone as an ascii string \code{GMT}, rather
>  than a numeric \code{-0000}. This is needed for some protocols (such
> -as HTTP). This only applies when \var{localtime} is \code{False}
> +as HTTP). This only applies when \var{localtime} is \code{False}.
> +New in Python 2.4.
>  \end{funcdesc}
>  
>  \begin{funcdesc}{make_msgid}{\optional{idstring}}

Wouldn't that be \versionadded{2.4}?

Reinhold

-- 
Mail address is perfectly valid!


From anthony at interlink.com.au  Sun Jul 17 15:21:28 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Sun, 17 Jul 2005 23:21:28 +1000
Subject: [Python-Dev] [C++-sig]  GCC version compatibility
In-Reply-To: <20050717100609.GB3581@lap200.cdc.informatik.tu-darmstadt.de>
References: <u8y0jz762.fsf@boost-consulting.com>
	<200507171601.23780.anthony@interlink.com.au>
	<20050717100609.GB3581@lap200.cdc.informatik.tu-darmstadt.de>
Message-ID: <200507172321.31665.anthony@interlink.com.au>


> I prepared the patch for 2.4.2 since it is indeed a bugfix. The current
> test produces wrong results if the compiler is GCC 4.0 which inhibits a
> successful build of Python 2.4.

I should probably add that I'm not flagging that I think there's a problem
here. I'm mostly urging caution - I hate having to cut brown-paper-bag 
releases <wink>. If possible, can the folks on c++-sig try this patch
out and put their results in the patch discussion? If you're keen, you 
could try jumping onto HP's testdrive systems (http://www.testdrive.hp.com/).
From what I recall, they have a bunch of systems with non-gcc C++ compilers,
including the DEC^WDigital^Compaq^WHP one on the alphas, and the HP C++ 
compiler on the HP/UX boxes[1].

(and, it should be added, I very much appreciate the work you've put into
fixing this problem)


Anthony


[1] dunno how useful the HP/UX C++ compiler is going to be - last time I
was exposed to it, many years ago, it was... not good. 
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

From skip at pobox.com  Sun Jul 17 17:36:15 2005
From: skip at pobox.com (skip@pobox.com)
Date: Sun, 17 Jul 2005 10:36:15 -0500
Subject: [Python-Dev] python/dist/src/Doc/lib emailutil.tex,1.11,1.12
In-Reply-To: <dbdktu$ag2$1@sea.gmane.org>
References: <E1Du7ca-0005NL-Ga@sc8-pr-cvs1.sourceforge.net>
	<dbdktu$ag2$1@sea.gmane.org>
Message-ID: <17114.31471.59663.51998@montanaro.dyndns.org>


    Reinhold> Wouldn't that be \versionadded{2.4}?

Yes, thanks.  Corrected.

Skip

From martin at v.loewis.de  Sun Jul 17 19:06:42 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 17 Jul 2005 19:06:42 +0200
Subject: [Python-Dev] Adding the 'path' module (was Re: Some RFE for
	review)
In-Reply-To: <50862ebd050717012676126cbd@mail.gmail.com>
References: <d9mmd6$gjf$1@sea.gmane.org>	
	<5.1.1.6.0.20050627111913.035e2660@mail.telecommunity.com>	
	<ca471dc20506272343cbe7614@mail.gmail.com>	
	<50862ebd05063016466f3e6abd@mail.gmail.com>	
	<ca471dc2050703112845321ad3@mail.gmail.com>	
	<50862ebd05070317183d971bef@mail.gmail.com>	
	<ca471dc205070400441ab49ffb@mail.gmail.com>	
	<42D749FB.6040506@v.loewis.de>	
	<50862ebd05071600305f162f38@mail.gmail.com>	
	<42DA0B98.7020700@v.loewis.de>
	<50862ebd050717012676126cbd@mail.gmail.com>
Message-ID: <42DA9022.1020608@v.loewis.de>

Neil Hodgson wrote:
>    There is WC_NO_BEST_FIT_CHARS to defeat that. It says that it will
> use the default character if the translation can't be round-tripped.
> Available on WIndows 2000 and XP but not NT4. 

Ah, ok, that's a useful feature. Of course, limited availability of the
feature means that we either need to drop support for some systems, or
provide yet another layer of fallback routines.

Regards,
Martin

From mwh at python.net  Mon Jul 18 13:33:46 2005
From: mwh at python.net (Michael Hudson)
Date: Mon, 18 Jul 2005 12:33:46 +0100
Subject: [Python-Dev] 'With' context documentation draft (was Re:
 Terminology for PEP 343
In-Reply-To: <42D83A7F.9010300@gmail.com> (Nick Coghlan's message of "Sat,
	16 Jul 2005 08:36:47 +1000")
References: <000701c57e8f$86c35ae0$aa36c797@oemcomputer>
	<42C75006.6090902@ronadam.com> <42C7E146.4090403@gmail.com>
	<42C91A07.9030402@gmail.com> <42CBBC92.4040804@gmail.com>
	<42CEF42E.9040204@egenix.com> <42CF1DB5.6090602@gmail.com>
	<42D6B9D0.1010309@egenix.com> <2mslyg2ywp.fsf@starship.python.net>
	<42D814C0.3020703@ronadam.com>
	<ca471dc205071513054c944117@mail.gmail.com>
	<42D83414.7030200@ronadam.com> <42D83A7F.9010300@gmail.com>
Message-ID: <2mk6jo2vs5.fsf@starship.python.net>

Nick Coghlan <ncoghlan at gmail.com> writes:

> Ron Adam wrote:
>>      3. The "with" documentation could possibly be grouped with or after 
>> the "try" documentation as it may be easier to understand in that context.
>
> I was looking for an appropriate place in the tutorial to put a couple of 
> usage examples - a new subsection immediately after the introduction of 
> try/finally (8.7, IIRC) seemed to make the most sense.
>
> However, I figured that bit could wait until I had a chance to play with an 
> actual implementation.

http://python.org/sf/1235943

(I have a more recent patch at home, which better implements the
__future__ stuff in the compiler package -- not a very big thing).

Probably also want to test with Phillip's PEP 342 patch:

http://python.org/sf/1223381

(I haven't done this, there are probably conflicts).

Cheers,
mwh

-- 
  Lisp does badly because we refuse to lie.  When people ask us if 
  we can solve insoluble problems we say that we can't, and because 
  they expect us to lie to them, they find some other language
  where the truth is less respected.   -- Tim Bradshaw, comp.lang.lisp

From pbagora at yahoo.com  Tue Jul 19 19:16:42 2005
From: pbagora at yahoo.com (Pranav Bagora)
Date: Tue, 19 Jul 2005 10:16:42 -0700 (PDT)
Subject: [Python-Dev] read only files
Message-ID: <20050719171642.52192.qmail@web32402.mail.mud.yahoo.com>

Hello,

I am getting a permission denied error when i am
trying to make changes in some read only files. How
can we check and change the properties of a file in
the program itself.

Please help,
Pranav

Pranav Bagora 
Graduate Student 
SUNY Binghamton. 
================
Add:- 261 Main Street
Apt No. 11
Binghamton NY. 
================
Phone:- 607 349 8788
email:-   pbagora at binghamton.edu
 











		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

From tjreedy at udel.edu  Tue Jul 19 19:42:04 2005
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 19 Jul 2005 13:42:04 -0400
Subject: [Python-Dev] read only files
References: <20050719171642.52192.qmail@web32402.mail.mud.yahoo.com>
Message-ID: <dbje1c$i7u$1@sea.gmane.org>


"Pranav Bagora" <pbagora at yahoo.com> wrote in message 
news:20050719171642.52192.qmail at web32402.mail.mud.yahoo.com...
> I am getting a permission denied error...
> Please help,

The Python-dev mailing list (or gmane.comp.python.devel newsgroup) is for 
development of future Python releases.  Please direct help questions to 
comp.lang.python or the general python mailing list.




From rspivak at nuxeo.com  Tue Jul 19 23:27:16 2005
From: rspivak at nuxeo.com (Ruslan Spivak)
Date: Wed, 20 Jul 2005 00:27:16 +0300
Subject: [Python-Dev] builtin filter function
Message-ID: <1121808436.2831.54.camel@alienoid.is.ua>

Hello.

I was reading source code for bltinmodule.c and found probably erroneus
stuff in filter function. I'm newbie to python inners and don't know if
attached code is worth for a patch submission.

I would appreciate if someone could take a look at it and if it's ok
then i'll make submission, otherwise just drop it.
TIA

Ruslan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bltinmodule_filter.diff
Type: text/x-patch
Size: 3880 bytes
Desc: 
Url : http://mail.python.org/pipermail/python-dev/attachments/20050720/30e81ca5/bltinmodule_filter.bin

From reinhold-birkenfeld-nospam at wolke7.net  Wed Jul 20 00:27:57 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Wed, 20 Jul 2005 00:27:57 +0200
Subject: [Python-Dev] builtin filter function
In-Reply-To: <1121808436.2831.54.camel@alienoid.is.ua>
References: <1121808436.2831.54.camel@alienoid.is.ua>
Message-ID: <dbjugu$3cp$1@sea.gmane.org>

Ruslan Spivak wrote:
> Hello.
> 
> I was reading source code for bltinmodule.c and found probably erroneus
> stuff in filter function. I'm newbie to python inners and don't know if
> attached code is worth for a patch submission.
> 
> I would appreciate if someone could take a look at it and if it's ok
> then i'll make submission, otherwise just drop it.
> TIA

This is indeed a bug in the function, and could have caused memory leaks
because of not releasing the preallocated tuple.

Since this is evident, I fixed it by now (Python/bltinmodule.c r2.318.2.1 and
r2.322), but in the future you should always post patches to SourceForge to
avoid crowding python-dev.

But above all, thank you for spotting this issue and helping to make Python
more bug-free!

Reinhold


-- 
Mail address is perfectly valid!


From rspivak at nuxeo.com  Wed Jul 20 00:32:59 2005
From: rspivak at nuxeo.com (Ruslan Spivak)
Date: Wed, 20 Jul 2005 01:32:59 +0300
Subject: [Python-Dev] builtin filter function
In-Reply-To: <dbjugu$3cp$1@sea.gmane.org>
References: <1121808436.2831.54.camel@alienoid.is.ua>
	<dbjugu$3cp$1@sea.gmane.org>
Message-ID: <1121812379.2831.60.camel@alienoid.is.ua>

? ???, 20/07/2005 ? 00:27 +0200, Reinhold Birkenfeld ?????:
> Ruslan Spivak wrote:
> > Hello.
> > 
> > I was reading source code for bltinmodule.c and found probably erroneus
> > stuff in filter function. I'm newbie to python inners and don't know if
> > attached code is worth for a patch submission.
> > 
> > I would appreciate if someone could take a look at it and if it's ok
> > then i'll make submission, otherwise just drop it.
> > TIA
> 
> This is indeed a bug in the function, and could have caused memory leaks
> because of not releasing the preallocated tuple.
> 
> Since this is evident, I fixed it by now (Python/bltinmodule.c r2.318.2.1 and
> r2.322), but in the future you should always post patches to SourceForge to
> avoid crowding python-dev.

Thanks, i promise next time i'll post to SourceForge :)

> 
> But above all, thank you for spotting this issue and helping to make Python
> more bug-free!

Glad i was somehow helpful.

Ruslan



From reinhold-birkenfeld-nospam at wolke7.net  Wed Jul 20 00:40:39 2005
From: reinhold-birkenfeld-nospam at wolke7.net (Reinhold Birkenfeld)
Date: Wed, 20 Jul 2005 00:40:39 +0200
Subject: [Python-Dev] builtin filter function
In-Reply-To: <dbjugu$3cp$1@sea.gmane.org>
References: <1121808436.2831.54.camel@alienoid.is.ua>
	<dbjugu$3cp$1@sea.gmane.org>
Message-ID: <dbjv8o$57u$1@sea.gmane.org>

Reinhold Birkenfeld wrote:
> Ruslan Spivak wrote:
>> Hello.
>> 
>> I was reading source code for bltinmodule.c and found probably erroneus
>> stuff in filter function. I'm newbie to python inners and don't know if
>> attached code is worth for a patch submission.
>> 
>> I would appreciate if someone could take a look at it and if it's ok
>> then i'll make submission, otherwise just drop it.
>> TIA
> 
> This is indeed a bug in the function, and could have caused memory leaks
> because of not releasing the preallocated tuple.

Correction: should have been "not releasing the iterator". (However, the bug
would have been triggered only if the tuple could not be allocated, which is
a very unlikely case).

Reinhols

-- 
Mail address is perfectly valid!


From gvanrossum at gmail.com  Wed Jul 20 02:45:07 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Tue, 19 Jul 2005 17:45:07 -0700
Subject: [Python-Dev] builtin filter function
In-Reply-To: <1121808436.2831.54.camel@alienoid.is.ua>
References: <1121808436.2831.54.camel@alienoid.is.ua>
Message-ID: <ca471dc205071917455dede0c4@mail.gmail.com>

On 7/19/05, Ruslan Spivak <rspivak at nuxeo.com> wrote:
> I was reading source code for bltinmodule.c and found probably erroneus
> stuff in filter function. I'm newbie to python inners and don't know if
> attached code is worth for a patch submission.
> 
> I would appreciate if someone could take a look at it and if it's ok
> then i'll make submission, otherwise just drop it.

As was already said, thanks for your contribution!

I noticed in your patch that you also did "whitespace normalization"
of the file before diffing it. This is generally not a good idea -- it
distracts the reader of the patch from the actual bug the patch is
fixing. In your case, 4 out of 6 patch chunks were spurious.

We do like to keep our whitespace normalized, but as a rule we only do
this in patches that don't make otherwise significant changes, so that
the semantic changes are separate from the cleanups.

That's a minor nit, however -- thanks for finding the memory leak!

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

From martin.blais at gmail.com  Wed Jul 20 05:13:02 2005
From: martin.blais at gmail.com (Martin Blais)
Date: Tue, 19 Jul 2005 23:13:02 -0400
Subject: [Python-Dev] while:
Message-ID: <8393fff05071920137f55ff01@mail.gmail.com>

Hi

Today I typed something funny in the interactive interpreter:


>>> while:
  File "<stdin>", line 1
    while:
         ^
SyntaxError: invalid syntax


it got me wondering, wouldn't it be nice if

   while:
      ...

behaved as:

   while True:
      ...

Since they appeared, I started using "while True:" instead of "while
1:" for this common idiom.  I find it reveals the intention better,
but I don't like the typing.

Opinions?

cheers,

From anthony at interlink.com.au  Wed Jul 20 05:26:19 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Wed, 20 Jul 2005 13:26:19 +1000
Subject: [Python-Dev] while:
In-Reply-To: <8393fff05071920137f55ff01@mail.gmail.com>
References: <8393fff05071920137f55ff01@mail.gmail.com>
Message-ID: <200507201326.21410.anthony@interlink.com.au>

On Wednesday 20 July 2005 13:13, Martin Blais wrote:
> it got me wondering, wouldn't it be nice if
>
>    while:
>       ...
>
> behaved as:
>
>    while True:
>       ...

-1

I don't expect if: or for: to mean anything, so why
should while: ? I don't see any advantages to it (saving
5 keypresses? please...)

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

From rudd-o at amautacorp.com  Wed Jul 20 06:06:43 2005
From: rudd-o at amautacorp.com (Manuel Amador)
Date: Tue, 19 Jul 2005 23:06:43 -0500
Subject: [Python-Dev] while:
In-Reply-To: <200507201326.21410.anthony@interlink.com.au>
References: <8393fff05071920137f55ff01@mail.gmail.com>
	<200507201326.21410.anthony@interlink.com.au>
Message-ID: <1121832403.11006.29.camel@master.amauta>

El mi?, 20-07-2005 a las 13:26 +1000, Anthony Baxter escribi?:
> On Wednesday 20 July 2005 13:13, Martin Blais wrote:
> > it got me wondering, wouldn't it be nice if
> >
> >    while:
> >       ...
> >
> > behaved as:
> >
> >    while True:
> >       ...
> 
> -1
> 
> I don't expect if: or for: to mean anything, so why
> should while: ? I don't see any advantages to it (saving
> 5 keypresses? please...)

maybe a new idiom

forever:
    ...

is in order?

(perhaps it would be better to call it "always:" or "until_break")

(this message is a bit tongue-in-cheek)

=)

> 
> Anthony
-- 
Manuel Amador                   <rudd-o at amautacorp.com>
http://www.amautacorp.com/            +593 (4) 220-7010

From facundobatista at gmail.com  Wed Jul 20 06:22:15 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 20 Jul 2005 01:22:15 -0300
Subject: [Python-Dev] while:
In-Reply-To: <8393fff05071920137f55ff01@mail.gmail.com>
References: <8393fff05071920137f55ff01@mail.gmail.com>
Message-ID: <e04bdf3105071921221eedee8d@mail.gmail.com>

On 7/20/05, Martin Blais <martin.blais at gmail.com> wrote:

> it got me wondering, wouldn't it be nice if
> 
>    while:
>       ...
> 
> behaved as:
> 
>    while True:

-1

Explicit is better than implicit.

Regards,

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From rspivak at nuxeo.com  Wed Jul 20 08:44:56 2005
From: rspivak at nuxeo.com (Ruslan Spivak)
Date: Wed, 20 Jul 2005 09:44:56 +0300
Subject: [Python-Dev] builtin filter function
In-Reply-To: <ca471dc205071917455dede0c4@mail.gmail.com>
References: <1121808436.2831.54.camel@alienoid.is.ua>
	<ca471dc205071917455dede0c4@mail.gmail.com>
Message-ID: <1121841896.2800.5.camel@alienoid.is.ua>

? ???, 19/07/2005 ? 17:45 -0700, Guido van Rossum ?????:
> On 7/19/05, Ruslan Spivak <rspivak at nuxeo.com> wrote:
> > I was reading source code for bltinmodule.c and found probably erroneus
> > stuff in filter function. I'm newbie to python inners and don't know if
> > attached code is worth for a patch submission.
> > 
> > I would appreciate if someone could take a look at it and if it's ok
> > then i'll make submission, otherwise just drop it.
> 
> As was already said, thanks for your contribution!
> 
> I noticed in your patch that you also did "whitespace normalization"
> of the file before diffing it. This is generally not a good idea -- it
> distracts the reader of the patch from the actual bug the patch is
> fixing. In your case, 4 out of 6 patch chunks were spurious.
> 
> We do like to keep our whitespace normalized, but as a rule we only do
> this in patches that don't make otherwise significant changes, so that
> the semantic changes are separate from the cleanups.
> 

Thanks for this note, i'll keep that in mind next time.

Ruslan


From martin.blais at gmail.com  Thu Jul 21 02:22:15 2005
From: martin.blais at gmail.com (Martin Blais)
Date: Wed, 20 Jul 2005 20:22:15 -0400
Subject: [Python-Dev] while:
In-Reply-To: <e04bdf3105071921221eedee8d@mail.gmail.com>
References: <8393fff05071920137f55ff01@mail.gmail.com>
	<e04bdf3105071921221eedee8d@mail.gmail.com>
Message-ID: <8393fff05072017224bab6e51@mail.gmail.com>

On 7/20/05, Facundo Batista <facundobatista at gmail.com> wrote:
> On 7/20/05, Martin Blais <martin.blais at gmail.com> wrote:
> 
> > it got me wondering, wouldn't it be nice if
> >
> >    while:
> >       ...
> >
> > behaved as:
> >
> >    while True:
> 
> -1
> 
> Explicit is better than implicit.

Well, maybe you're reading a bit too litterally into that statement. 
To me the expression is very explicitly absent :-)    More seriously,
reading into these rules too literally leads to funny places: I could
ask why at the end of functions there is an implicit "return None"
(I'm not expecting an answer).  Explicit better than implicit?

The Rule of Least Surprise says to me that "while:" would do the least
unexpected thing.  There are only two possibilities: the test is
implicitly false, in which case "while:" would make no sense (i.e. the
block would be ignored).  Therefore the other only sensible case is
that the test is implicitly true, which can be useful (and also
happens to be a very common idiom).

It's not so much about saving typing characters: it's just low-hanging
fruit that simplifies the language a little bit (well, "simplify" is
arguable though, if you consider the grammar it makes it a tiny bit
more complex, but that is usually not the programmer's point-of-view).

Bah, whatever, +0

cheers,

From facundobatista at gmail.com  Thu Jul 21 02:58:21 2005
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 20 Jul 2005 21:58:21 -0300
Subject: [Python-Dev] while:
In-Reply-To: <8393fff05072017224bab6e51@mail.gmail.com>
References: <8393fff05071920137f55ff01@mail.gmail.com>
	<e04bdf3105071921221eedee8d@mail.gmail.com>
	<8393fff05072017224bab6e51@mail.gmail.com>
Message-ID: <e04bdf3105072017584628553d@mail.gmail.com>

On 7/20/05, Martin Blais <martin.blais at gmail.com> wrote:

> Well, maybe you're reading a bit too litterally into that statement.
> To me the expression is very explicitly absent :-)    More seriously,
> reading into these rules too literally leads to funny places: I could
> ask why at the end of functions there is an implicit "return None"
> (I'm not expecting an answer).  Explicit better than implicit?

See your point.

But, for me (spanish speaker), if I read a ``while:``, I think, "while what?".

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From kbk at shore.net  Thu Jul 21 06:04:00 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 21 Jul 2005 00:04:00 -0400 (EDT)
Subject: [Python-Dev] Weekly Python Patch/Bug Summary
Message-ID: <200507210404.j6L4409Y028359@bayview.thirdcreek.com>

Patch / Bug Summary
___________________

Patches :  350 open ( +1) /  2882 closed ( +2) /  3232 total ( +3)
Bugs    :  889 open ( -8) /  5141 closed (+22) /  6030 total (+14)
RFE     :  189 open ( -5) /   178 closed ( +8) /   367 total ( +3)

New / Reopened Patches
______________________

Add unicode for sys.argv, os.environ, os.system  (2005-07-02)
CLOSED http://python.org/sf/1231336  reopened by  loewis

Fix LINKCC (Bug #1189330)  (2005-07-15)
       http://python.org/sf/1239112  opened by  Christoph Ludwig

Prevent race condition in os.makedirs  (2005-07-17)
       http://python.org/sf/1239890  opened by  Nir Soffer

release lock on exception in threading.Thread.join()  (2005-07-18)
       http://python.org/sf/1240614  opened by  Dirk Groeneveld

Patches Closed
______________

Patch for potential buffer overrun in tokenizer.c  (2005-01-13)
       http://python.org/sf/1101726  closed by  doerwalter

Add unicode for sys.argv, os.environ, os.system  (2005-07-02)
       http://python.org/sf/1231336  closed by  loewis

Optimization for textwrap  (2005-05-26)
       http://python.org/sf/1209527  closed by  rhettinger

New / Reopened Bugs
___________________

email.Generator traceback in forwarded msg  (2005-07-12)
       http://python.org/sf/1236906  opened by  Skip Montanaro

Missing sk_SK in windows_locale  (2005-07-13)
       http://python.org/sf/1237015  opened by  Lukas Lalinsky

link path probs on OSX re: Tcl, Tk & fink's /sw  (2005-07-13)
       http://python.org/sf/1237697  opened by  blakers

threading.Thread uses {} as default argument  (2005-07-14)
CLOSED http://python.org/sf/1238170  opened by  Simon Dahlbacka

manual.cls contains an invalid pdf-inquiry  (2005-07-14)
       http://python.org/sf/1238210  opened by  Michael Schindler

freed pointer is used in longobject.c:long_pow()  (2005-07-15)
CLOSED http://python.org/sf/1238681  opened by  Luke

subprocess.Popen fails inside a Windows service  (2005-07-15)
       http://python.org/sf/1238747  opened by  Adam Kerrison

Win registry problem  (2005-07-15)
       http://python.org/sf/1239120  opened by  Bruce Sherwood

Win registry problem  (2005-07-15)
CLOSED http://python.org/sf/1239148  opened by  Bruce Sherwood

Install Error: "cannot compute sizeof (int), 77"  (2005-07-15)
       http://python.org/sf/1239186  opened by  Bob Gazzale

email.Utils.formatdate documetaion missing  (2005-07-17)
CLOSED http://python.org/sf/1239681  opened by  Nir Soffer

distutils: MetroWerks support can go  (2005-07-17)
       http://python.org/sf/1239948  opened by  Jack Jansen

Distutils does not use logging  (2005-07-19)
       http://python.org/sf/1241006  opened by  Giles Antonio Radford

StreamReader broken for byte string to byte string codecs  (2005-07-20)
CLOSED http://python.org/sf/1241507  opened by  Graham Horler

garbage collection asserts failing  (2005-07-20)
       http://python.org/sf/1241545  opened by  munder12

-m does not find dotted modules  (2005-07-20)
CLOSED http://python.org/sf/1241619  opened by  Giles Antonio Radford

Bugs Closed
___________

debug info file descriptor of tarfile is inconsistent  (2005-07-09)
       http://python.org/sf/1235266  closed by  birkenfeld

missing Py_DECREF in PyObject_CallMethod  (2005-06-29)
       http://python.org/sf/1229429  closed by  mwh

Mistakes in online docs under "5.3 Pure Embedding"  (2005-07-05)
       http://python.org/sf/1232768  closed by  birkenfeld

tkFileDialog.askopen... fails when dir=""  (2005-07-07)
       http://python.org/sf/1233799  closed by  birkenfeld

Carbon.FSSpec.as_pathname() crashes  (2005-07-11)
       http://python.org/sf/1236090  closed by  jackjansen

segfault/assert in tokenizer  (2004-12-21)
       http://python.org/sf/1089395  closed by  doerwalter

threading.Thread uses {} as default argument  (2005-07-14)
       http://python.org/sf/1238170  closed by  birkenfeld

some latex reject the pdfinfo  macro while generating html  (2004-11-22)
       http://python.org/sf/1071094  closed by  birkenfeld

freed pointer is used in longobject.c:long_pow()  (2005-07-15)
       http://python.org/sf/1238681  closed by  tim_one

Win registry problem  (2005-07-15)
       http://python.org/sf/1239148  closed by  bsherwood

email.Utils.formatdate documetaion missing  (2005-07-17)
       http://python.org/sf/1239681  closed by  montanaro

"k" specifier in PyArg_ParseTuple incomplete documentated  (2004-11-07)
       http://python.org/sf/1061920  closed by  birkenfeld

"article id" in description of NNTP objects  (2004-08-24)
       http://python.org/sf/1015140  closed by  birkenfeld

Missing urllib.urlretrieve docs  (2004-08-24)
       http://python.org/sf/1014761  closed by  birkenfeld

refman doesn't know about universal newlines  (2005-01-10)
       http://python.org/sf/1099363  closed by  birkenfeld

7.5.6 Thread Objects is too vague  (2004-03-09)
       http://python.org/sf/912943  closed by  birkenfeld

os.access() documentation should stress race conditions  (2004-01-08)
       http://python.org/sf/872769  closed by  birkenfeld

use first_name, not first, in code samples  (2004-09-03)
       http://python.org/sf/1021621  closed by  birkenfeld

make frameworkinstall fails for non-default location  (2005-06-09)
       http://python.org/sf/1217591  closed by  jackjansen

SocketServer module documentation misleading  (2004-05-20)
       http://python.org/sf/957505  closed by  birkenfeld

unclear documentation/missing command?  (2003-11-27)
       http://python.org/sf/850238  closed by  birkenfeld

os module: Need a better description of &quot;mode&quot;  (2003-06-17)
       http://python.org/sf/755617  closed by  birkenfeld

StreamReader broken for byte string to byte string codecs  (2005-07-20)
       http://python.org/sf/1241507  closed by  doerwalter

New / Reopened RFE
__________________

add a note to eval and exec to not use it when possible  (2005-07-13)
CLOSED http://python.org/sf/1237678  opened by  Reinhold Birkenfeld

add dedent() string method  (2005-07-13)
       http://python.org/sf/1237680  opened by  Reinhold Birkenfeld

RFE Closed
__________

add a note to eval and exec to not use it when possible  (2005-07-13)
       http://python.org/sf/1237678  closed by  rhettinger

Links to tutorials and howtos from references  (2005-07-04)
       http://python.org/sf/1232073  closed by  rhettinger

Add Jason Orendorff's path module to stdlib  (2005-06-23)
       http://python.org/sf/1226256  closed by  rhettinger

Add Error Code Dictionary to urllib2  (2005-06-08)
       http://python.org/sf/1216944  closed by  birkenfeld

Floating point second in date/time tuple  (2001-04-05)
       http://python.org/sf/414059  closed by  birkenfeld

pickle lacks float('inf')  (2001-07-28)
       http://python.org/sf/445484  closed by  birkenfeld

Optional type enforcement  (2003-07-28)
       http://python.org/sf/778763  closed by  birkenfeld

-m does not find dotted modules  (2005-07-20)
       http://python.org/sf/1241619  closed by  rhettinger


From gmccaughan at synaptics-uk.com  Thu Jul 21 16:17:22 2005
From: gmccaughan at synaptics-uk.com (Gareth McCaughan)
Date: Thu, 21 Jul 2005 15:17:22 +0100
Subject: [Python-Dev] while:
In-Reply-To: <8393fff05072017224bab6e51@mail.gmail.com>
References: <8393fff05071920137f55ff01@mail.gmail.com>
	<e04bdf3105071921221eedee8d@mail.gmail.com>
	<8393fff05072017224bab6e51@mail.gmail.com>
Message-ID: <200507211517.24016.gmccaughan@synaptics-uk.com>

On Thursday 2005-07-21 01:22, Martin Blais wrote:

> The Rule of Least Surprise says to me that "while:" would do the least
> unexpected thing.  There are only two possibilities: the test is
> implicitly false, in which case "while:" would make no sense (i.e. the
> block would be ignored).  Therefore the other only sensible case is
> that the test is implicitly true, which can be useful (and also
> happens to be a very common idiom).

To me, the "least unexpected thing" for "while:" to do is to
raise a syntax error. The principle of least surprise doesn't
mean that for every sequence of tokens you should pick the
least surprising thing it could do, and give it that definition.
(That's what they do in C++, except for the bit about picking
the least surprising semantics.)

-- 
g


From rspivak at nuxeo.com  Thu Jul 21 20:55:11 2005
From: rspivak at nuxeo.com (Ruslan Spivak)
Date: Thu, 21 Jul 2005 21:55:11 +0300
Subject: [Python-Dev] while:
In-Reply-To: <e04bdf3105072017584628553d@mail.gmail.com>
References: <8393fff05071920137f55ff01@mail.gmail.com>
	<e04bdf3105071921221eedee8d@mail.gmail.com>
	<8393fff05072017224bab6e51@mail.gmail.com>
	<e04bdf3105072017584628553d@mail.gmail.com>
Message-ID: <1121972110.3062.2.camel@alienoid.is.ua>

? ???, 20/07/2005 ? 21:58 -0300, Facundo Batista ?????:
> On 7/20/05, Martin Blais <martin.blais at gmail.com> wrote:
> 
> > Well, maybe you're reading a bit too litterally into that statement.
> > To me the expression is very explicitly absent :-)    More seriously,
> > reading into these rules too literally leads to funny places: I could
> > ask why at the end of functions there is an implicit "return None"
> > (I'm not expecting an answer).  Explicit better than implicit?
> 
> See your point.
> 
> But, for me (spanish speaker), if I read a ``while:``, I think, "while what?".
> 

The same here, so -1 for while:

Ruslan



From weezer at MIT.EDU  Fri Jul 22 16:33:11 2005
From: weezer at MIT.EDU (Christine C Moran)
Date: Fri, 22 Jul 2005 10:33:11 -0400 (EDT)
Subject: [Python-Dev] Information request;
 Keywords: compiler compiler, EBNF, python, ISO 14977
In-Reply-To: <mailman.4666.1122037309.10510.python-dev@python.org>
References: <mailman.4666.1122037309.10510.python-dev@python.org>
Message-ID: <Pine.GSO.4.58L.0507220910170.23689@biohazard-cafe.mit.edu>

Apart from the SimpleParse module, are there other good parser generators
out there for python in python that accept EBNF style grammars?
Preferably ISO 14977 EBNF.

-xstinex

From Michaels at rd.bbc.co.uk  Fri Jul 22 16:19:52 2005
From: Michaels at rd.bbc.co.uk (Michael Sparks)
Date: Fri, 22 Jul 2005 15:19:52 +0100
Subject: [Python-Dev] Information request;
	Keywords: compiler compiler, EBNF, python, ISO 14977
In-Reply-To: <Pine.GSO.4.58L.0507220910170.23689@biohazard-cafe.mit.edu>
References: <mailman.4666.1122037309.10510.python-dev@python.org>
	<Pine.GSO.4.58L.0507220910170.23689@biohazard-cafe.mit.edu>
Message-ID: <200507221519.52072.Michaels@rd.bbc.co.uk>

On Friday 22 Jul 2005 15:33, Christine C Moran wrote:
> Apart from the SimpleParse module, are there other good parser generators
> out there for python in python that accept EBNF style grammars?
> Preferably ISO 14977 EBNF.

This is off-topic for python-dev.  Please post to comp.lang.python
instead.


Michael.
-- 
Michael Sparks, Senior R&D Engineer, Digital Media Group
Michael.Sparks at rd.bbc.co.uk, http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This e-mail may contain personal views which are not the views of the BBC.

From Scott.Daniels at Acm.Org  Sat Jul 23 13:33:42 2005
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Sat, 23 Jul 2005 04:33:42 -0700
Subject: [Python-Dev] zlib 1.2.3 is just out
Message-ID: <dbt9um$77d$1@sea.gmane.org>

Note zlib 1.2.3 is just out -- the zlib compression/decompression

     http://www.zlib.net/

 From the page:
     Version 1.2.3 eliminates potential security vulnerabilities in zlib
     1.2.1 and 1.2.2, so all users of those versions should upgrade
     immediately. The following important fixes are provided in
     zlib 1.2.3 over 1.2.1 and 1.2.2:

     * Eliminate a potential security vulnerability when decoding
       invalid compressed data
     * Eliminate a potential security vulnerability when decoding
       specially crafted compressed data
     * Fix a bug when decompressing dynamic blocks with no distance codes
     * Fix crc check bug in gzread() after gzungetc()
     * Do not return an error when using gzread() on an empty file

I'd guess this belongs in 2.5, with a possible retrofit for 2.4.

--Scott David Daniels
Scott.Daniels at Acm.Org


From raymond.hettinger at verizon.net  Sat Jul 23 14:34:18 2005
From: raymond.hettinger at verizon.net (Raymond Hettinger)
Date: Sat, 23 Jul 2005 08:34:18 -0400
Subject: [Python-Dev] zlib 1.2.3 is just out
In-Reply-To: <dbt9um$77d$1@sea.gmane.org>
Message-ID: <000001c58f82$d8b099e0$c926a044@oemcomputer>

> Note zlib 1.2.3 is just out -- the zlib compression/decompression
 . . .

> I'd guess this belongs in 2.5, with a possible retrofit for 2.4.

+1 on backporting, but that is up to Anthony.


Raymond


From skip at pobox.com  Sun Jul 24 15:34:59 2005
From: skip at pobox.com (skip@pobox.com)
Date: Sun, 24 Jul 2005 08:34:59 -0500
Subject: [Python-Dev] should doc string content == documentation content?
Message-ID: <17123.39171.94235.217898@montanaro.dyndns.org>

There's a new bug report on SF (#1243553) complaining (that's probably not
the right word) that the documentation for cgi.escape available from pydoc
isn't as detailed as that in the full documentation.  Is there any desire to
make the runtime documentation available via pydoc or help() as detailed as
the full documentation?  I'm inclined to think that while it might be a
noble goal, it's probably not worth the effort for several reasons.

    1. Many objects don't lend themselves to inline documentation.  This
       includes all the basic data types (strings, numbers, lists, tuples,
       dicts).  It could be achieved perhaps by some sort of hackery (e.g.,
       for object foo present the contents of _foo__doc__ if it was a string
       or unicode object), but that would only be a convention.

    2. There's so much more to the documentation than documenting individual
       objects.

    3. When asking pydoc (or help()) to present a module's documentation, it
       displays a URL for the full module documentation.

    4. It would be a *ton* of work.

While I can fix the isolated case of cgi.escape fairly easily, I'm not
inclined to.  (I will gladly do it if the sentiment is that picking off such
low-hanging fruit is worthwhile.)  What do other people think?

Skip


From fdrake at acm.org  Sun Jul 24 17:55:48 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sun, 24 Jul 2005 11:55:48 -0400
Subject: [Python-Dev] should doc string content == documentation content?
In-Reply-To: <17123.39171.94235.217898@montanaro.dyndns.org>
References: <17123.39171.94235.217898@montanaro.dyndns.org>
Message-ID: <200507241155.48482.fdrake@acm.org>

On Sunday 24 July 2005 09:34, skip at pobox.com wrote:
 > detailed as the full documentation?  I'm inclined to think that while it
 > might be a noble goal, it's probably not worth the effort for several
 > reasons.

All your reasons not to include all the documentation in the docstrings are 
good.  I'll add:

    5. It would be a maintenance problem keeping the two sets of docs in sync.

    6. Most Python processes don't need the docs anyway.  I suspect the
       docstrings are used primarily in the interactive interpreter and other
       development tools.  Zope 2 is the only application that uses
       docstrings at runtime that I'm aware of.  Given that Zope 3 abandons
       this, I'm not inclined to take that as a guiding example.

 > While I can fix the isolated case of cgi.escape fairly easily, I'm not
 > inclined to.  (I will gladly do it if the sentiment is that picking off
 > such low-hanging fruit is worthwhile.)  What do other people think?

The low-hanging fruit, of course, is to close the report with a 'reject' 
status.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From tim.peters at gmail.com  Sun Jul 24 18:37:42 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Sun, 24 Jul 2005 12:37:42 -0400
Subject: [Python-Dev] should doc string content == documentation content?
In-Reply-To: <17123.39171.94235.217898@montanaro.dyndns.org>
References: <17123.39171.94235.217898@montanaro.dyndns.org>
Message-ID: <1f7befae05072409371a7d034a@mail.gmail.com>

[Skip]
> There's a new bug report on SF (#1243553) complaining (that's probably not
> the right word) that the documentation for cgi.escape available from pydoc
> isn't as detailed as that in the full documentation.  Is there any desire to
> make the runtime documentation available via pydoc or help() as detailed as
> the full documentation?

I'm sure there is <wink>, but via a different route:  tools to extract
text from the full documentation, not to burden docstrings with an
impossible task.  Channeling Guido, docstrings are best when they have
a "quick reference card" feel, more memory aid than textbook.  That
doesn't mean it wouldn't also be nice to have "the textbook" online
from pydoc/help too, it means that manuals and docstrings serve
different purposes.

> ...

> While I can fix the isolated case of cgi.escape fairly easily, I'm not
> inclined to.  (I will gladly do it if the sentiment is that picking off such
> low-hanging fruit is worthwhile.)  What do other people think?

The cgi.escape docstring _should_ admit to the optional boolan `quote`
argument.  I'm not sure why it uses the highfalutin' "SGML entities"
either, when the full docs are content to use the plain-folks
"HTML-safe" (if anything, I'd expect the full docs to be anal and the
docstring to be "friendly").  But that's criticism of the docstring
_as_ a docstring, not criticizing the docstring for, e.g., not
mentioning xml.sax.saxutils.quoteattr() too.

From tlesher at gmail.com  Sun Jul 24 19:23:39 2005
From: tlesher at gmail.com (Tim Lesher)
Date: Sun, 24 Jul 2005 13:23:39 -0400
Subject: [Python-Dev] should doc string content == documentation content?
In-Reply-To: <1f7befae05072409371a7d034a@mail.gmail.com>
References: <17123.39171.94235.217898@montanaro.dyndns.org>
	<1f7befae05072409371a7d034a@mail.gmail.com>
Message-ID: <9613db6005072410233ffdf66d@mail.gmail.com>

On 7/24/05, Tim Peters <tim.peters at gmail.com> wrote:
> I'm sure there is <wink>, but via a different route:  tools to extract
> text from the full documentation, not to burden docstrings with an
> impossible task.  Channeling Guido, docstrings are best when they have
> a "quick reference card" feel, more memory aid than textbook.  That
> doesn't mean it wouldn't also be nice to have "the textbook" online
> from pydoc/help too, it means that manuals and docstrings serve
> different purposes.

While I agree that docstrings shouldn't be a deep copy of _Python in a
Nutshell_, there are definitely some areas of the standard library
that could use some help.  threading comes to mind immediately.
-- 
Tim Lesher <tlesher at gmail.com>

From tim.peters at gmail.com  Sun Jul 24 19:58:56 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Sun, 24 Jul 2005 13:58:56 -0400
Subject: [Python-Dev] should doc string content == documentation content?
In-Reply-To: <9613db6005072410233ffdf66d@mail.gmail.com>
References: <17123.39171.94235.217898@montanaro.dyndns.org>
	<1f7befae05072409371a7d034a@mail.gmail.com>
	<9613db6005072410233ffdf66d@mail.gmail.com>
Message-ID: <1f7befae050724105857ee75c@mail.gmail.com>

[Tim Lesher]
> While I agree that docstrings shouldn't be a deep copy of _Python in a
> Nutshell_, there are definitely some areas of the standard library
> that could use some help.  threading comes to mind immediately.

Sure!  The way to cure that one is to write better docstrings for
threading -- go for it.

From martin at v.loewis.de  Sun Jul 24 23:46:25 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 24 Jul 2005 23:46:25 +0200
Subject: [Python-Dev] zlib 1.2.3 is just out
In-Reply-To: <000001c58f82$d8b099e0$c926a044@oemcomputer>
References: <000001c58f82$d8b099e0$c926a044@oemcomputer>
Message-ID: <42E40C31.1020902@v.loewis.de>

Raymond Hettinger wrote:
>>I'd guess this belongs in 2.5, with a possible retrofit for 2.4.
> 
> 
> +1 on backporting, but that is up to Anthony.

Correct me if I'm wrong - but there isn't much "porting" to this.
AFAICT, this is only relevant for the Windows build (i.e. which
version is used in the binaries). For the source distribution, there
should be no change (except for PCbuild/readme.txt, which should
reflect the version that is used in the Windows build). FWIW,
this currently talks about 1.2.1.

Regards,
Martin

From mal at egenix.com  Mon Jul 25 00:41:14 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 25 Jul 2005 00:41:14 +0200
Subject: [Python-Dev] should doc string content == documentation content?
In-Reply-To: <17123.39171.94235.217898@montanaro.dyndns.org>
References: <17123.39171.94235.217898@montanaro.dyndns.org>
Message-ID: <42E4190A.9090303@egenix.com>

skip at pobox.com wrote:
> There's a new bug report on SF (#1243553) complaining (that's probably not
> the right word) that the documentation for cgi.escape available from pydoc
> isn't as detailed as that in the full documentation.  Is there any desire to
> make the runtime documentation available via pydoc or help() as detailed as
> the full documentation?  I'm inclined to think that while it might be a
> noble goal, it's probably not worth the effort for several reasons.
> 
>     1. Many objects don't lend themselves to inline documentation.  This
>        includes all the basic data types (strings, numbers, lists, tuples,
>        dicts).  It could be achieved perhaps by some sort of hackery (e.g.,
>        for object foo present the contents of _foo__doc__ if it was a string
>        or unicode object), but that would only be a convention.
> 
>     2. There's so much more to the documentation than documenting individual
>        objects.
> 
>     3. When asking pydoc (or help()) to present a module's documentation, it
>        displays a URL for the full module documentation.
> 
>     4. It would be a *ton* of work.
> 
> While I can fix the isolated case of cgi.escape fairly easily, I'm not
> inclined to.  (I will gladly do it if the sentiment is that picking off such
> low-hanging fruit is worthwhile.)  What do other people think?

-1 on bloating the source code with documentation that's easily
fetchable from the python.org web-site.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 25 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From martin.blais at gmail.com  Mon Jul 25 01:24:51 2005
From: martin.blais at gmail.com (Martin Blais)
Date: Sun, 24 Jul 2005 19:24:51 -0400
Subject: [Python-Dev] should doc string content == documentation content?
In-Reply-To: <200507241155.48482.fdrake@acm.org>
References: <17123.39171.94235.217898@montanaro.dyndns.org>
	<200507241155.48482.fdrake@acm.org>
Message-ID: <8393fff0507241624284ff476@mail.gmail.com>

On 7/24/05, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
> On Sunday 24 July 2005 09:34, skip at pobox.com wrote:
>  > detailed as the full documentation?  I'm inclined to think that while it
>  > might be a noble goal, it's probably not worth the effort for several
>  > reasons.
> 
> All your reasons not to include all the documentation in the docstrings are
> good.  I'll add:
> 
>     5. It would be a maintenance problem keeping the two sets of docs in sync.

This ties well with the discussion on Doc-SIG a few months ago about
manual docs vs. in-code docs.   If a system could be devised to "pull"
the docstrings into the manual (at appropriate places), the issue of
syncing the docs partially goes away.

cheers,

From greg.ewing at canterbury.ac.nz  Mon Jul 25 03:56:33 2005
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 25 Jul 2005 13:56:33 +1200
Subject: [Python-Dev] should doc string content == documentation content?
In-Reply-To: <200507241155.48482.fdrake@acm.org>
References: <17123.39171.94235.217898@montanaro.dyndns.org>
	<200507241155.48482.fdrake@acm.org>
Message-ID: <42E446D1.2080506@canterbury.ac.nz>

Fred L. Drake, Jr. wrote:

>     6. Most Python processes don't need the docs anyway.  I suspect the
>        docstrings are used primarily in the interactive interpreter and other
>        development tools.

Maybe docstrings should be kept in a separate part of the
.pyc file, and not loaded into memory until requested?

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From chuckr at chuckr.org  Mon Jul 25 04:43:51 2005
From: chuckr at chuckr.org (Chuck Robey)
Date: Sun, 24 Jul 2005 22:43:51 -0400
Subject: [Python-Dev] installation of python on a Zaurus
Message-ID: <42E451E7.4000406@chuckr.org>

I'm trying to get Python installed on a Zaurus, running OpenBSD.  There 
are several problems with the basic install, some of which I've fixed, 
more I haven't.  I need a particulare question solved here, so I'm going 
to ffer in recompense what I'ver learned so far:  The configure script 
seems to know (from internal comments) that _XOPEN_SOURCES must be 
turned off, but it's not efectively turned off, and the configure script 
needs to ber edited, else you can't even get the basic build to even 
begin.  I don't know enough abou tocnfigure to offer a correct fix, but 
this is true (I hand-edited the configure script to turn xopen_sources 
to "no".

What I'm after is the reason why it keeps on telling me (during the 
build, not during configure) that it can't find my just installed tcl85 
and tk85 libs.  I have soft-linked them to a more common naming 
(libtcl.so.1.0 and libtk.so.1.0, which is the same index, just dropping 
the "85" from the naming, and doing the ldconfig'ing ok) but this 
doesn't seem to fix it.  There is a configure-time thing about UCS-tcl, 
and I don't know what this is.  It IS in configure, I can't even locate 
the source of the complaint about not finding the tcl libs, it's not in 
the top level directory anywhere.

Appreciate the help.

From aahz at pythoncraft.com  Mon Jul 25 15:04:53 2005
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 25 Jul 2005 06:04:53 -0700
Subject: [Python-Dev] installation of python on a Zaurus
In-Reply-To: <42E451E7.4000406@chuckr.org>
References: <42E451E7.4000406@chuckr.org>
Message-ID: <20050725130453.GA27192@panix.com>

On Sun, Jul 24, 2005, Chuck Robey wrote:
>
> I'm trying to get Python installed on a Zaurus, running OpenBSD.  

While python-dev can be a good place to get questions like this
answered, many more people read comp.lang.python, and you should ask
there, too.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.

From fdrake at acm.org  Mon Jul 25 15:54:10 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 25 Jul 2005 09:54:10 -0400
Subject: [Python-Dev] should doc string content == documentation content?
In-Reply-To: <8393fff0507241624284ff476@mail.gmail.com>
References: <17123.39171.94235.217898@montanaro.dyndns.org>
	<200507241155.48482.fdrake@acm.org>
	<8393fff0507241624284ff476@mail.gmail.com>
Message-ID: <200507250954.10756.fdrake@acm.org>

On Sunday 24 July 2005 19:24, Martin Blais wrote:
 > This ties well with the discussion on Doc-SIG a few months ago about
 > manual docs vs. in-code docs.   If a system could be devised to "pull"
 > the docstrings into the manual (at appropriate places), the issue of
 > syncing the docs partially goes away.

Yes, it does.  Avoiding the maintenance burden is a matter of having only one 
source for the docs, and doesn't not inform the selection of which place is 
best in a substantial way.  A little though.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From edcjones at comcast.net  Mon Jul 25 22:37:55 2005
From: edcjones at comcast.net (Edward C. Jones)
Date: Mon, 25 Jul 2005 16:37:55 -0400
Subject: [Python-Dev] C api for built-in type set?
Message-ID: <42E54DA3.4010509@comcast.net>

Is there a C API for the built-in type set? if not, why not?

From barry at python.org  Mon Jul 25 22:47:15 2005
From: barry at python.org (Barry Warsaw)
Date: Mon, 25 Jul 2005 16:47:15 -0400
Subject: [Python-Dev] C api for built-in type set?
In-Reply-To: <42E54DA3.4010509@comcast.net>
References: <42E54DA3.4010509@comcast.net>
Message-ID: <1122324435.23146.18.camel@geddy.wooz.org>

On Mon, 2005-07-25 at 16:37, Edward C. Jones wrote:
> Is there a C API for the built-in type set? if not, why not?

Sadly, no.  Because no one's written it yet...?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050725/39765e73/attachment.pgp

From raymond.hettinger at verizon.net  Mon Jul 25 23:03:45 2005
From: raymond.hettinger at verizon.net (Raymond Hettinger)
Date: Mon, 25 Jul 2005 17:03:45 -0400
Subject: [Python-Dev] C api for built-in type set?
In-Reply-To: <42E54DA3.4010509@comcast.net>
Message-ID: <003101c5915c$5902c660$b931c797@oemcomputer>

[Edward C. Jones]
> Is there a C API for the built-in type set? 
> if not, why not?

I decided not to expose the internals until the code was fully evolved.
For Py2.5, the underlying implementation is shifting to use its own data
structure instead of forwarding everything to dictionaries.  That will
save a substantial amount of memory and offer a tiny speed boost.  See a
fully-tested draft implementation in nondist/sandbox/set.

Of course, you already know that you can use the PyObject_Call() and its
brethren to access sets and set methods.  The regular, external set API
works pretty well with this approach (many methods accept any iterable).
The only inefficiencies that arise are with fine grained methods like
__contains__() and add(); even then, it is no less efficient than pure
Python.


Raymond Hettinger


From trentm at ActiveState.com  Tue Jul 26 03:39:36 2005
From: trentm at ActiveState.com (Trent Mick)
Date: Mon, 25 Jul 2005 18:39:36 -0700
Subject: [Python-Dev] zlib 1.2.3 is just out
In-Reply-To: <42E40C31.1020902@v.loewis.de>
References: <000001c58f82$d8b099e0$c926a044@oemcomputer>
	<42E40C31.1020902@v.loewis.de>
Message-ID: <20050726013936.GA30956@ActiveState.com>

[Martin v. L?wis wrote]
> Raymond Hettinger wrote:
> >>I'd guess this belongs in 2.5, with a possible retrofit for 2.4.
> > 
> > 
> > +1 on backporting, but that is up to Anthony.
> 
> Correct me if I'm wrong - but there isn't much "porting" to this.
> AFAICT, this is only relevant for the Windows build (i.e. which
> version is used in the binaries). For the source distribution, there
> should be no change (except for PCbuild/readme.txt, which should
> reflect the version that is used in the Windows build). FWIW,
> this currently talks about 1.2.1.

Here is a patch to do this (attached) that works on the trunk and
against the Python-2.4.1.tgz source tarball. Shall I check this into the
HEAD and release24-maint?

Trent

-- 
Trent Mick
TrentM at ActiveState.com
-------------- next part --------------
Index: PCbuild/readme.txt
===================================================================
RCS file: /cvsroot/python/python/dist/src/PCbuild/readme.txt,v
retrieving revision 1.59
diff -u -r1.59 readme.txt
--- python/PCbuild/readme.txt	6 Jul 2005 19:34:10 -0000	1.59
+++ python/PCbuild/readme.txt	26 Jul 2005 00:53:17 -0000
@@ -126,15 +126,15 @@
 
 zlib
     Python wrapper for the zlib compression library.  Get the source code
-    for version 1.2.1 from a convenient mirror at:
+    for version 1.2.3 from a convenient mirror at:
         http://www.gzip.org/zlib/
-    Unpack into dist\zlib-1.2.1.
+    Unpack into dist\zlib-1.2.3.
     A custom pre-link step in the zlib project settings should manage to
-    build zlib-1.2.1\zlib.lib by magic before zlib.pyd (or zlib_d.pyd) is
+    build zlib-1.2.3\zlib.lib by magic before zlib.pyd (or zlib_d.pyd) is
     linked in PCbuild\.
     However, the zlib project is not smart enough to remove anything under
-    zlib-1.2.1\ when you do a clean, so if you want to rebuild zlib.lib
-    you need to clean up zlib-1.2.1\ by hand.
+    zlib-1.2.3\ when you do a clean, so if you want to rebuild zlib.lib
+    you need to clean up zlib-1.2.3\ by hand.
 
 bz2
     Python wrapper for the libbz2 compression library.  Homepage
Index: PCbuild/zlib.vcproj
===================================================================
RCS file: /cvsroot/python/python/dist/src/PCbuild/zlib.vcproj,v
retrieving revision 1.6
diff -u -r1.6 zlib.vcproj
--- python/PCbuild/zlib.vcproj	20 Jul 2004 14:37:48 -0000	1.6
+++ python/PCbuild/zlib.vcproj	26 Jul 2005 00:53:17 -0000
@@ -21,7 +21,7 @@
 			<Tool
 				Name="VCCLCompilerTool"
 				Optimization="0"
-				AdditionalIncludeDirectories="..\Include,..\PC,..\..\zlib-1.2.1"
+				AdditionalIncludeDirectories="..\Include,..\PC,..\..\zlib-1.2.3"
 				PreprocessorDefinitions="_DEBUG;WIN32;_WINDOWS"
 				RuntimeLibrary="3"
 				UsePrecompiledHeader="2"
@@ -37,7 +37,7 @@
 				Name="VCCustomBuildTool"/>
 			<Tool
 				Name="VCLinkerTool"
-				AdditionalDependencies="..\..\zlib-1.2.1\zlib.lib"
+				AdditionalDependencies="..\..\zlib-1.2.3\zlib.lib"
 				OutputFile="./zlib_d.pyd"
 				LinkIncremental="1"
 				SuppressStartupBanner="TRUE"
@@ -63,7 +63,7 @@
 			<Tool
 				Name="VCPreLinkEventTool"
 				Description="Checking static zlib has been built"
-				CommandLine="cd ..\..\zlib-1.2.1
+				CommandLine="cd ..\..\zlib-1.2.3
 nmake -nologo -f win32\Makefile.msc zlib.lib
 "/>
 			<Tool
@@ -92,7 +92,7 @@
 				Name="VCCLCompilerTool"
 				Optimization="2"
 				InlineFunctionExpansion="1"
-				AdditionalIncludeDirectories="..\Include,..\PC,..\..\zlib-1.2.1"
+				AdditionalIncludeDirectories="..\Include,..\PC,..\..\zlib-1.2.3"
 				PreprocessorDefinitions="NDEBUG;WIN32;_WINDOWS"
 				StringPooling="TRUE"
 				RuntimeLibrary="2"
@@ -110,7 +110,7 @@
 				Name="VCCustomBuildTool"/>
 			<Tool
 				Name="VCLinkerTool"
-				AdditionalDependencies="..\..\zlib-1.2.1\zlib.lib"
+				AdditionalDependencies="..\..\zlib-1.2.3\zlib.lib"
 				OutputFile="./zlib.pyd"
 				LinkIncremental="1"
 				SuppressStartupBanner="TRUE"
@@ -136,7 +136,7 @@
 			<Tool
 				Name="VCPreLinkEventTool"
 				Description="Checking static zlib has been built"
-				CommandLine="cd ..\..\zlib-1.2.1
+				CommandLine="cd ..\..\zlib-1.2.3
 nmake -nologo -f win32\Makefile.msc zlib.lib
 "/>
 			<Tool
@@ -166,7 +166,7 @@
 				AdditionalOptions=" /USECL:MS_ITANIUM"
 				Optimization="2"
 				InlineFunctionExpansion="1"
-				AdditionalIncludeDirectories="{MSSDKPATH}\include\Win64\atl;{MSSDKPATH}\include\Win64\crt;{MSSDKPATH}\include\Win64\crt\sys;{MSSDKPATH}\include\Win64\mfc;..\Include,..\PC,..\..\zlib-1.2.1"
+				AdditionalIncludeDirectories="{MSSDKPATH}\include\Win64\atl;{MSSDKPATH}\include\Win64\crt;{MSSDKPATH}\include\Win64\crt\sys;{MSSDKPATH}\include\Win64\mfc;..\Include,..\PC,..\..\zlib-1.2.3"
 				PreprocessorDefinitions="NDEBUG;WIN32;_WINDOWS"
 				StringPooling="TRUE"
 				BasicRuntimeChecks="0"
@@ -188,7 +188,7 @@
 			<Tool
 				Name="VCLinkerTool"
 				AdditionalOptions=" /MACHINE:IA64 /USELINK:MS_SDK"
-				AdditionalDependencies="..\..\zlib-1.2.1\zlib.lib"
+				AdditionalDependencies="..\..\zlib-1.2.3\zlib.lib"
 				OutputFile="./zlib.pyd"
 				LinkIncremental="1"
 				SuppressStartupBanner="TRUE"
@@ -214,7 +214,7 @@
 			<Tool
 				Name="VCPreLinkEventTool"
 				Description="Checking static zlib has been built"
-				CommandLine="cd ..\..\zlib-1.2.1
+				CommandLine="cd ..\..\zlib-1.2.3
 nmake -nologo -f win32\Makefile.msc zlib.lib
 "/>
 			<Tool

From tim.peters at gmail.com  Tue Jul 26 03:50:49 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 25 Jul 2005 21:50:49 -0400
Subject: [Python-Dev] zlib 1.2.3 is just out
In-Reply-To: <20050726013936.GA30956@ActiveState.com>
References: <000001c58f82$d8b099e0$c926a044@oemcomputer>
	<42E40C31.1020902@v.loewis.de>
	<20050726013936.GA30956@ActiveState.com>
Message-ID: <1f7befae0507251850793fc6ca@mail.gmail.com>

[Scott David Daniels]
>>>> I'd guess this belongs in 2.5, with a possible retrofit for 2.4.

[Raymond Hettinger]
>>> +1 on backporting, but that is up to Anthony.

[Martin v. L?wis wrote]
>> Correct me if I'm wrong - but there isn't much "porting" to this.
>> AFAICT, this is only relevant for the Windows build (i.e. which
>> version is used in the binaries). For the source distribution, there
>> should be no change (except for PCbuild/readme.txt, which should
>> reflect the version that is used in the Windows build). FWIW,
>> this currently talks about 1.2.1.

[Trent Mick]
> Here is a patch to do this (attached) that works on the trunk and
> against the Python-2.4.1.tgz source tarball. Shall I check this into the
> HEAD and release24-maint?

Definitely on HEAD, almost certainly on 24 maint.  The slight
uncertainty wrt the latter is due to the slim possibility that they
also made this version of zlib incompatible in some way.  I doubt
that, but I haven't tried it.

BTW, the NEWS files should add a blurb saying Python moved to a new
zlib, under a "Windows" section.

From trentm at ActiveState.com  Tue Jul 26 04:00:03 2005
From: trentm at ActiveState.com (Trent Mick)
Date: Mon, 25 Jul 2005 19:00:03 -0700
Subject: [Python-Dev] zlib 1.2.3 is just out
In-Reply-To: <1f7befae0507251850793fc6ca@mail.gmail.com>
References: <000001c58f82$d8b099e0$c926a044@oemcomputer>
	<42E40C31.1020902@v.loewis.de>
	<20050726013936.GA30956@ActiveState.com>
	<1f7befae0507251850793fc6ca@mail.gmail.com>
Message-ID: <20050726020003.GB30956@ActiveState.com>

> [Trent Mick]
> > Here is a patch to do this (attached) that works on the trunk and
> > against the Python-2.4.1.tgz source tarball. Shall I check this into the
> > HEAD and release24-maint?

[Tim Peters wrote]
> Definitely on HEAD, almost certainly on 24 maint.  The slight
> uncertainty wrt the latter is due to the slim possibility that they
> also made this version of zlib incompatible in some way.  I doubt
> that, but I haven't tried it.

Dunno. All tests in test_zlib pass.

> BTW, the NEWS files should add a blurb saying Python moved to a new
> zlib, under a "Windows" section.

Okay.

Trent


-- 
Trent Mick
TrentM at ActiveState.com

From anthony at interlink.com.au  Tue Jul 26 04:19:01 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue, 26 Jul 2005 12:19:01 +1000
Subject: [Python-Dev] zlib 1.2.3 is just out
In-Reply-To: <20050726013936.GA30956@ActiveState.com>
References: <000001c58f82$d8b099e0$c926a044@oemcomputer>
	<42E40C31.1020902@v.loewis.de>
	<20050726013936.GA30956@ActiveState.com>
Message-ID: <200507261219.03220.anthony@interlink.com.au>

On Tuesday 26 July 2005 11:39, Trent Mick wrote:
> Here is a patch to do this (attached) that works on the trunk and
> against the Python-2.4.1.tgz source tarball. Shall I check this into the
> HEAD and release24-maint?

Yes.


-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

From trentm at ActiveState.com  Tue Jul 26 04:38:28 2005
From: trentm at ActiveState.com (Trent Mick)
Date: Mon, 25 Jul 2005 19:38:28 -0700
Subject: [Python-Dev] zlib 1.2.3 is just out
In-Reply-To: <200507261219.03220.anthony@interlink.com.au>
References: <000001c58f82$d8b099e0$c926a044@oemcomputer>
	<42E40C31.1020902@v.loewis.de>
	<20050726013936.GA30956@ActiveState.com>
	<200507261219.03220.anthony@interlink.com.au>
Message-ID: <20050726023828.GC30956@ActiveState.com>

[Anthony Baxter wrote]
> On Tuesday 26 July 2005 11:39, Trent Mick wrote:
> > Here is a patch to do this (attached) that works on the trunk and
> > against the Python-2.4.1.tgz source tarball. Shall I check this into the
> > HEAD and release24-maint?
> 
> Yes.

Okay, done.

Can I say that I've had the pleasure for a long while now at only being
afflicted with Subversion and Perforce. We can't move Python CVS to
subversion soon enough. Then again with a checkin rate hovering belong
one per year... :)

HEAD:
    Checking in dist/src/Misc/NEWS;
    /cvsroot/python/python/dist/src/Misc/NEWS,v  <--  NEWS
    new revision: 1.1323; previous revision: 1.1322
    done
    Checking in dist/src/PCbuild/readme.txt;
    /cvsroot/python/python/dist/src/PCbuild/readme.txt,v  <--  readme.txt
    new revision: 1.60; previous revision: 1.59
    done
    Checking in dist/src/PCbuild/zlib.vcproj;
    /cvsroot/python/python/dist/src/PCbuild/zlib.vcproj,v  <--  zlib.vcproj
    new revision: 1.7; previous revision: 1.6
    done

release24-maint:
    Checking in dist/src/Misc/NEWS;
    /cvsroot/python/python/dist/src/Misc/NEWS,v  <--  NEWS
    new revision: 1.1193.2.66; previous revision: 1.1193.2.65
    done
    Checking in dist/src/PCbuild/readme.txt;
    /cvsroot/python/python/dist/src/PCbuild/readme.txt,v  <--  readme.txt
    new revision: 1.58.2.1; previous revision: 1.58
    done
    Checking in dist/src/PCbuild/zlib.vcproj;
    /cvsroot/python/python/dist/src/PCbuild/zlib.vcproj,v  <--  zlib.vcproj
    new revision: 1.6.4.1; previous revision: 1.6
    done


Trent

-- 
Trent Mick
TrentM at ActiveState.com

From steven.bethard at gmail.com  Thu Jul 28 07:33:49 2005
From: steven.bethard at gmail.com (Steven Bethard)
Date: Wed, 27 Jul 2005 23:33:49 -0600
Subject: [Python-Dev] python-dev summary for 2005-07-01 to 2005-07-15 [draft]
Message-ID: <d11dcfba050727223328e091db@mail.gmail.com>

Here's the draft for the first half of July.  Please look especially
close at the "GCC/G++ Issues on Linux" thread; I'm not sure I got all
the details right.

=============
Announcements
=============

------------------------------
QOTF (Quotes of the Fortnight)
------------------------------

Marc-Andre Lemburg provides perhaps the best summary to date of `how
strings and Unicode should be used`_ in Python:

   To untie this Gordian Knot, we should use strings and Unicode like
they are supposed to be used (in the context of text data):

   * strings are fine for text data that is encoded using the default encoding
   * Unicode should be used for all text data that is not or cannot be
encoded in the default encoding

   Later on in Py3k, all text data should be stored in Unicode and all
binary data in some new binary type.

On a more entertaining note, Anthony Baxter describes the general
outlook outlook on handling `threads vs signals`_:

    threads vs signals is a platform-dependant trail of misery,
despair, horror and madness

.. _how strings and Unicode should be used:
http://mail.python.org/pipermail/python-dev/2005-July/054854.html

.. _threads vs signals:
http://mail.python.org/pipermail/python-dev/2005-July/054832.html


=========
Summaries
=========

---------------------------------------
PEP 343 Documentation: Context Managers
---------------------------------------

Raymond Hettinger started a thread discussing how objects with
__enter__ and __exit__ methods should be referred to in the official
Python documentation. A few terms were thrown around, with "resource
manager" being one of the early favorites. However, because the
__enter__/__exit__ protocol handles a much more general construct that
just the acquisition and release of a resource, this term steadily
lost ground. Things like "locking objects are resource managed" and
"decimal.Context() is a resource manager" sounded awkward and hard to
explain.

Phillip J. Eby suggested that objects with __enter__ and __exit__
methods could be called "context managers", and people seemed
generally happy with this term. Nick Coghlan took this term, and some
example use cases for "context managers", and put together a `draft
documentation`_ for the section in the Python Library Reference.
People liked Nick's wording, and after a few minor revisions (mainly
to add more examples), it looked pretty complete.  Nick promised to
add a bit to the Python tutorial after he got a chance to play with
the PEP 342_/343_ implementations.

There was also a brief followup thread that discussed which objects in
the stdlib should gain __enter__ and __exit__ methods in Python 2.5.
It looks like decimal.Context objects will almost certainly become
context managers, and there is some chance that a
sys.redirected_stdout context manager might appear.

.. _draft documentation: http://www.python.org/sf/1234057
.. _342: http://www.python.org/sf/1223381
.. _343: http://python.org/sf/1235943

Contributing threads:

- `Terminology for PEP 343
<http://mail.python.org/pipermail/python-dev/2005-June/054525.html>`__
- `Terminology for PEP 343
<http://mail.python.org/pipermail/python-dev/2005-July/054530.html>`__
- `'With' context documentation draft (was Re: Terminology for PEP 343
<http://mail.python.org/pipermail/python-dev/2005-July/054658.html>`__
- `PEP 343 documentation on Sourceforge Patch tracker
<http://mail.python.org/pipermail/python-dev/2005-July/054688.html>`__
- `Possible context managers in stdlib
<http://mail.python.org/pipermail/python-dev/2005-July/054762.html>`__

[SJB]


-----------------------
GCC/G++ Issues on Linux
-----------------------

While in the past Python and Python extension modules could be
compiled on Linux with different GCC versions as long as the 'C' ABIs
were compatible, David Abrahams reported that Python extensions on
Linux now crash if they are not compiled with exactly the same version
of GCC as the Python they're loaded into. This is apparently due to
the fact that on these systems Python is being linked with CXX when it
should be linked with CC. The solution turned out to be to pass
--without-cxx to configure; if it is not specified, configure runs a
linking test that (improperly) determines that linking with CXX is
necessary. When the --without-cxx flag is specified, configure does
not perform this linking test, so Python is linked with CC.

In the same discussion, Christoph Ludwig pointed out another problem
in the above linking test.  The current test compiles a single TU
program using CXX and sees if linking it using CC fails. For GCC 3.x,
it does, but because GCC 4.0 does a better job of eliminating
unreachable code, with GCC 4.0 it does not. Thus make fails using GCC
4.0. Christoph showed that compiling a program with two TUs, one of
which calls an 'extern "C"' function in the other, restores the
original behavior. He provided the corresponding patch_ to
configure.in.

While Christoph's patch stops make from failing on Linux with ELF
shared binaries and GCC 4.x, it did not address David Abrahams
original concern -- that on Linux with ELF shared binaries and GCC 3.x
or 4.x, configure should determine that Python can be compiled
*without* CXX. Christoph promised to work on a more comprehensive
patch to address this problem for Python 2.5.

.. _patch: http://www.python.org/sf/1239112

Contributing threads:

- `GCC version compatibility
<http://mail.python.org/pipermail/python-dev/2005-July/054686.html>`__
- `Linux Python linking with G++?
<http://mail.python.org/pipermail/python-dev/2005-July/054693.html>`__
- `[C++-sig] GCC version compatibility
<http://mail.python.org/pipermail/python-dev/2005-July/054794.html>`__

[SJB]


--------------------------------------------------------
Behavior of Sourceforge when replying to python-checkins
--------------------------------------------------------

At the moment, replying to a message in the check-ins list defaults to
directing the reply to python-dev.  After this lead to some confusion,
Guido questioned whether this was a good idea or not; the two main
problems are that it is more difficult than necessary to send notes to
the committer, and difficult to follow such threads (the past is in
the check-in message, and future messages might be on python-dev or
the check-ins list).  Only one person replied to Guido's suggestion
(agreeing) - nothing appears to have changed so far, so it seems that
perhaps the status quo rules.

Contributing thread:

- `floatobject.c 2.136
<http://mail.python.org/pipermail/python-dev/2005-July/054617.html>`__

[TAM]


----------------------------------------
Removing else clauses from while and for
----------------------------------------

Thomas Lotze suggested that an 'eltry' keyword be introduced, to be
the counterpart of 'elif' for try statements; this idea was quickly
shot down by Guido (the use case is rare, using both "else" and "try"
is fine, a loop solution often works well).

As a result, however, Guido wondered whether else clauses on for/while
were a good idea, even though he dislikes flag variables.  He was
joined by various people, some of whom did not know (or had forgotten)
that the clauses even existed - some people wondered whether they made
the language harder to learn.  These people were outnumbered, though,
but people who felt that these loop else clauses were an elegant part
of the language and should definitely stay.

Interestingly, Guido noted that he wonders whether "elif" was a
mistake, and should have been "else if" (although there was no
indication that he felt that this should be changed in Python 3000).

Contributing thread:

- `Chaining try statements: eltry?
<http://mail.python.org/pipermail/python-dev/2005-July/054667.html>`__

[TAM]


---------------------------------------------------------
Adding Syntactic Support for Instance Variable Assignment
---------------------------------------------------------

Ralf W. Grosse-Kunstleve asked for syntactic support for the common idiom::

    def __init__(self, x, y, z):
        self.x = x
        self.y = y
        self.z = z

using the syntax::

    def __init__(self, .x, .y, .z):
        pass

People pointed out that with a properly-defined initialize() function
you could use existing Python syntax and only need a single function
call in __init__::

    def __init__(self, x, y, z):
        initialize(self, locals())

The thread_ was moved to comp.lang.python before it had a chance to
turn into a decorator-syntax-like discussion. ;)

.. _thread: http://mail.python.org/pipermail/python-list/2005-July/288292.html

Contributing thread:

- `reducing self.x=x; self.y=y; self.z=z boilerplate code
<http://mail.python.org/pipermail/python-dev/2005-July/054568.html>`__

[SJB]


-------------------------------------
Changing Triple-quoted String Parsing
-------------------------------------

Andrew Durdin suggested a change in the way that triple-quoted strings
are parsed. Strings like::

    myverylongvariablename = """\
            This line is indented,
        But this line is not.
        Note the trailing newline:
        """

would have the initial indents on all lines but the first ignored when
they were parsed. People seemed generally to dislike the proposal, for
a number of reasons:

- "It smells too much of DWIM, which is very unpythonic" -- Guido
- it is backwards incompatible in a number of ways
- textwrap.dedent covers pretty much all of the use cases

Andrew Durdin said he would write the PEP anway so that at least if
the idea was rejected, there would be some official documentation of
the rejection.

Contributing thread:

- `Triple-quoted strings and indentation
<http://mail.python.org/pipermail/python-dev/2005-July/054649.html>`__

[SJB]


-----------------------
path module and Unicode
-----------------------

Continuing last month's discussion on including the path module in the
standard library, Neil Hodgson pointed out that path makes it easier
to handle Unicode directory paths on Windows-based platforms;
currently, this requires user code. Further replies pointed out
similar Unicode handling problems in sys.argv and os.listdir, leading
Guido to comment, "Face it. Unicode stinks (from the programmer's
POV). But we'll have to live with it."

Neil boiled this down to four high-level strategies for dealing with
attributes that can Unicode: always returning Unicode, returning
Unicode only when a value can't be represented in ASCII, returning
Unicode only when a value can't be represented in the current code
page, or creating "separate-but-equal" APIs (like sys.argvu and
os.environu).  Marc-Andre Lemburg and Guido both expressed strong
preferences for the second option, with Marc-Andre formulating the
rule as presented in this issue's QotF.

Contributing threads:

- `Adding the 'path' module (was Re: Some RFE for review)
<http://mail.python.org/pipermail/python-dev/2005-July/054535.html>`__
- `Adding the 'path' module (was Re: Some RFE for review)
<http://mail.python.org/pipermail/python-dev/2005-July/054796.html>`__
- `Adding the 'path' module (was Re: Some RFE for review)
<http://mail.python.org/pipermail/python-dev/2005-July/054857.html>`__

[TDL]


--------------------------------------
Improving decimal module documentation
--------------------------------------

Facundo Batista noticed that documentation of the new-in-2.4 decimal
module was fairly limited, particularly in terms of the rounding
methods (although `PEP 327`_ covers them thoroughly).  Raymond
Hettinger volunteered to fix this up.

.. _PEP 327: http://www.python.org/peps/pep-0327.html
 

Contributing threads:

- `Decimal rounding doc
<http://mail.python.org/pipermail/python-dev/2005-July/054543.html>`__
- `Missing docs (was Decimal rounding doc)
<http://mail.python.org/pipermail/python-dev/2005-July/054553.html>`__

[TAM]


----------------
getch() behavior
----------------

Darryl Dixon pointed out that the getpass() function in the getpass
module does not accept extended characters on Windows, where the
msvcrt module is used to capture one character at a time from stdin
via the _getch() function defined in conio.h.  Windows supports
`capturing extended characters`_ via _getch, but it requires making a
second call to getch() if one of the 'magic' returns is encountered in
the first call (0x00 or 0xE0).  Darryl asked whether a patch for the
msvcrt module that added support for capturing extended characters
would be considered.  However, no support was received (although it
was suggested that a patch submitted through sourceforge, possibly
implemented via a new function, would be considered), as the thinness
of the msvcrt wrapper is intentional, and it was not clear that this
was a problem (i.e., that two calls could not be made).

.. _capturing extended characters:
http://support.microsoft.com/default.aspx?scid=kb;en-us;57888

Contributing threads:

- `getch() in msvcrt does not accept extended characters.
<http://mail.python.org/pipermail/python-dev/2005-June/054506.html>`__
- `getch() in msvcrt does not accept extended characters.
<http://mail.python.org/pipermail/python-dev/2005-July/054539.html>`__

[TAM]


-------------------
Threads and signals
-------------------

Florent Pillet noticed that when using Python 2.3 on Max OS X, calling
tmpfile() from a C extension had the side-effect of disabling
Control-C keyboard interruption (SIGINT).  Further digging revealed
that on both Darwin and FreeBSD platforms, tmpfile() does play with
the signal handling, but appears to change it back.  Michael Hudson
noted that Florent's code also involved threads, and that mixing
threads and signal handling involved "enormously subtle" issues. 
Anthony Baxter also replied that Python 2.4 should be less subject to
harmful effects from these bugs, but as a rule, mixing threads and
signals is a recipe for "misery, despair, horror, and madness."

Contributing threads:

- `C bindings calling tmpfile() blocks interrupt signal
<http://mail.python.org/pipermail/python-dev/2005-July/054690.html>`__

[TDL]


--------
List API
--------

Nicolas Fleury proposed adding copy() and clear() functions to lists,
to be more consistent with dict and set.  It was pointed out that the
copy module (copy.copy()) can be used for generic copying, or a copy
constructor and that clearing can be done with slicing (l[:] = []) or
the del keyword (del l[:]).  Advocates of the clear method argued that
a clear method would be easy to find in documentation, and wouldn't
require understanding slicing to use it, but none of the developers
seemed swayed, so it seems unlikely that anything more will come of
this at this time.

Contributing threads:

- `List copy and clear (was Re: Inconsistent API for sets.Set and
build-in set) <http://mail.python.org/pipermail/python-dev/2005-June/054522.html>`__
- `List copy and clear (was Re: Inconsistent API for sets.Set and
build-in set) <http://mail.python.org/pipermail/python-dev/2005-July/054527.html>`__

[TAM]


------------
Money Module
------------

Facundo Batista announced that the `Money module`_ is taking form
quickly, a "pre-PEP", and unit tests have been written. Raymond
Hettinger and Aahz noted that a "pre-PEP" is really a misnomer: PEPs
describe enhancements to the Python core and standard library, while
Money is still rather experimental and unlikely to see inclusion
anytime soon.  Facundo invited any interested parties to join the
discussion in the pymoney-general list on SourceForge.

.. _Money module: http://sourceforge.net/projects/pymoney

Contributing threads:

- `Money module
<http://mail.python.org/pipermail/python-dev/2005-July/054558.html>`__

[TDL]


------------------------
Bug-reporting Checklists
------------------------

Brett Cannon posted a draft of a checklist to help users report bugs.
Several minor improvements were suggested, but Raymond Hettinger
expressed mild dislike for the idea, describing it as "administrivia"
that might actually prevent people from filing bugs. Terry Reedy
suggested, along with the checklists, some minor changes to the
structure of the python.org site (to define bugs, help determine
whether a bug has already been reported, etc.) would help even more.

Contributing threads:

- `checklist for filing a bug
<http://mail.python.org/pipermail/python-dev/2005-July/054737.html>`__

[TDL]


===============
Skipped Threads
===============
- `how to create single exe dos file
<http://mail.python.org/pipermail/python-dev/2005-July/054536.html>`__
- `cephes module missing
<http://mail.python.org/pipermail/python-dev/2005-July/054537.html>`__
- `Inconsistent API for sets.Set and build-in set
<http://mail.python.org/pipermail/python-dev/2005-July/054560.html>`__
- `python-dev Summary for 2005-06-16 through 2005-06-30 [draft]
<http://mail.python.org/pipermail/python-dev/2005-July/054624.html>`__
- `using pyhon from the MSYS shell
<http://mail.python.org/pipermail/python-dev/2005-July/054636.html>`__
- `Possible C API problem?
<http://mail.python.org/pipermail/python-dev/2005-July/054638.html>`__
- `Weekly Python Patch/Bug Summary
<http://mail.python.org/pipermail/python-dev/2005-July/054648.html>`__
- `Expanding max chunk size to 4GB.
<http://mail.python.org/pipermail/python-dev/2005-July/054671.html>`__
- `Request to add developer
<http://mail.python.org/pipermail/python-dev/2005-July/054674.html>`__
- `C bindings calling tmpfileblocks interrupt signal
<http://mail.python.org/pipermail/python-dev/2005-July/054690.html>`__
- `Another SoC student for CVS access
<http://mail.python.org/pipermail/python-dev/2005-July/054718.html>`__
- `__autoinit__
<http://mail.python.org/pipermail/python-dev/2005-July/054788.html>`__
- `SF patch #1214889 - file.encoding support
<http://mail.python.org/pipermail/python-dev/2005-July/054870.html>`__
- `e-mail addresses
<http://mail.python.org/pipermail/python-dev/2005-July/054874.html>`__
- `[Python-checkins] python/dist/src/Miscdevelopers.txt, 1.15, 1.16
<http://mail.python.org/pipermail/python-dev/2005-July/054876.html>`__
- `Is PEP 237 final -- Unifying Long Integers and Integers
<http://mail.python.org/pipermail/python-dev/2005-July/054879.html>`__
- `Python on PyPI
<http://mail.python.org/pipermail/python-dev/2005-July/054880.html>`__

From gvanrossum at gmail.com  Thu Jul 28 16:53:23 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Thu, 28 Jul 2005 07:53:23 -0700
Subject: [Python-Dev] python-dev summary for 2005-07-01 to 2005-07-15
	[draft]
In-Reply-To: <d11dcfba050727223328e091db@mail.gmail.com>
References: <d11dcfba050727223328e091db@mail.gmail.com>
Message-ID: <ca471dc2050728075321f6c403@mail.gmail.com>

On 7/27/05, Steven Bethard <steven.bethard at gmail.com> wrote:
> Here's the draft for the first half of July.

Thanks! This is looking great! (Although I can't help you with the
GCC/C++ thread -- I've been avoiding that one like the plague myself.
:-)

To all the contributors, great job guys!

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

From martin at v.loewis.de  Thu Jul 28 22:00:00 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 28 Jul 2005 22:00:00 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Message-ID: <42E93940.6080708@v.loewis.de>

I'd like to see the Python source be stored in Subversion instead
of CVS, and on python.org instead of sf.net. To facilitate discussion,
I have drafted a PEP describing the rationale for doing so, and
the technical procedure to be performed.

This is for discussion on python-dev and eventual BDFL pronouncement;
if you see a reason not to make such a change, or if you would prefer
a different procedure, please speak up. Encouragement and support is
welcome, as well :-)

Regards,
Martin

PEP: XXX
Title: Migrating the Python CVS to Subversion
Version: $Revision $
Last-Modified: $Date$
Author: Martin v. L?wis <martin at v.loewis.de>
Discussions-To: <python-dev at python.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 14-Jul-2004
Post-History: 14-Jul-2004


Abstract
========

The Python source code is currently managed in a CVS repository on
sourceforge.net. This PEP proposes to move it to a subversion repository
on svn.python.org.

Rationale
=========

This change has two aspects: moving from CVS to subversion, and
moving from SourceForge to python.org. For each, a rationale will
be given.

Moving to Subversion
--------------------
CVS has a number of limitations that have been elimintation by
Subversion. For the development of Python, the most notable improvements
are:
- ability to rename files and directories, and to remove directories,
  while keeping the history of these files.
- support for change sets (sets of correlated changes to multiple
  files) through global revision numbers.
- support for offline diffs, which is useful when creating patches.

Moving to python.org
--------------------
SourceForge has kindly provided an important infrastructure for the
past years. Unfortunately, the attention that SF received has also
caused repeated overload situations in the past, to which the SF
operators could not always respond in a timely manner. In particular,
for CVS, they had to reduce the load on the primary CVS server by
introducing a second, read-only CVS server for anonymous access.
This server is regularly synchronized, but behind the the read-write
CVS repository between synchronizations. As a result, users without
commit access can see recent changes to the repository only with
a delay.

On python.org, it would be possible to make the repository accessible
for anonymous access.

Migration Procedure
===================

To move the Python CVS repository, the following steps need to be
executed. The steps are elaborated in more detail in the next
sections.

1. Assign passwords for all current committers for use on svn.python.org.
   User names on SF and svn.python.org should be identical, unless some
   committer requests a different user name.
2. At the beginning of the migration, announce that the repository on
   SourceForge closed.
3. 24 hours after the last commit, download the CVS repository.
4. Convert the CVS repository into two subversion repositories,
   one for distutils and one for Python.
5. Publish the repositories for write access for all committers,
   and anonymous read access.
6. Disable CVS access on SF.

Assign Passwords
================

Currently, access to Subversion on svn.python.org uses WebDAV over
https, using basic authentication. For this to work, authorized
users need to provide a password. This mechanism should be used,
atleast initially, for the Python CVS as well, since various committers
also have a username/password pair for the www SVN repository already.

Alternatives to password-based access include:
- Subversion over SSH, using SSH key pairs. This would require
  to give committers accounts on the machine, which currently is
  ruled out by the administration policy of svn.python.org.
- Subversion over WebDAV, using SSL client certificates. This
  would work, but would require to administrate a certificate
  authority.

Downloading the CVS Repository
==============================

The CVS repository can be downloaded from

http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.bz2

Since this tarball is generated only once a day, some time after
the repository freeze must pass before the tarball can be picked
up. It should be verified that the last commit, as recorded on
the python-commits mailing list, is indeed included in the tarball.

Converting the CVS Repository
=============================

The Python CVS repository contains two modules: distutils and
python. Keeping them together will produce quite long repository
URLs, so it is more convenient if the Python CVS and the distutils
CVS are converted into two separate repositories.

As the repository format, fsfs should be used (requires Subversion 1.1).
fsfs has the advantage of being more backup-friendly, as it allows to
backup a repository incrementally, without requiring to run any dump
commands.

The conversion should be done using cvs2svn utility, available e.g.
in the cvs2svn Debian package. The command for converting the Python
repository is

cvs2svn -q --encoding=latin1 --force-branch=cnri-16-start
--force-branch=descr-branch --force-branch=release152p1-patches
--force-tag=r16b1 --fs-type=fsfs -s py.svn.new python/python

The command to convert the distutils repository is

cvs2svn -q --encoding=latin1 --fs-type=fsfs -s dist.svn.new python/distutils

Sample results of this conversion are available at

http://www.dcl.hpi.uni-potsdam.de/python/
http://www.dcl.hpi.uni-potsdam.de/distutils/

Publish the Repositories
========================

The repositories should be published at https://svn.python.org/python
and https://svn.python.org/distutils. Read-write should be granted
through basic authentication to all current SF committers; read-only
access should be granted anonymously. As an option, websvn (available
e.g. from the Debian websvn package) could be provided.

The current SF project admins should get write access to the password
file, in order to create or delete new users.

Disable CVS
===========

It appears that CVS cannot be disabled entirely. Only the user interface
can be removed from the project page; the repository itself remains
available. If desired, write access to the python and distutils modules
can be disabled through a commitinfo entry.

From gvanrossum at gmail.com  Thu Jul 28 22:20:14 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Thu, 28 Jul 2005 13:20:14 -0700
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E93940.6080708@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
Message-ID: <ca471dc205072813205fe3d89f@mail.gmail.com>

On 7/28/05, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I'd like to see the Python source be stored in Subversion instead
> of CVS, and on python.org instead of sf.net. To facilitate discussion,
> I have drafted a PEP describing the rationale for doing so, and
> the technical procedure to be performed.

In principle I'm +1 on this (both aspects). I don't know enough to
understand all the subtleties.

I hope we're correctly estimating the effort required to manage the
server and the users. Managing users is especially important -- if a
user is compromised (as has happened in the past for python.org users)
the whole repository is compromised. Now this could happen to SF users
too, but I'm not sure that we know all the tricks in the book to
prevent attacks; SF has been doing this for years and that's an aspect
of SF that I trust (I think I've heard that they have even modified
their SSH server to be stricter).

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

From phd at mail2.phd.pp.ru  Thu Jul 28 23:15:41 2005
From: phd at mail2.phd.pp.ru (Oleg Broytmann)
Date: Fri, 29 Jul 2005 01:15:41 +0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E93940.6080708@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
Message-ID: <20050728211541.GA26983@phd.pp.ru>

On Thu, Jul 28, 2005 at 10:00:00PM +0200, "Martin v. L?wis" wrote:
> I'd like to see the Python source be stored in Subversion instead
> of CVS, and on python.org instead of sf.net.

   +1, +1.

> CVS has a number of limitations that have been elimintation by
> Subversion. For the development of Python, the most notable improvements
> are:
> - ability to rename files and directories, and to remove directories,
>   while keeping the history of these files.
> - support for change sets (sets of correlated changes to multiple
>   files) through global revision numbers.
> - support for offline diffs, which is useful when creating patches.

-- transactional operation - a changeset is either committed or rolled back
   at once;
-- very effective (both in terms of speed and memory) tagging and
   branching; tags and branches are very easy to understand and use in SVN.

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

From foom at fuhm.net  Thu Jul 28 23:58:03 2005
From: foom at fuhm.net (James Y Knight)
Date: Thu, 28 Jul 2005 17:58:03 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <ca471dc205072813205fe3d89f@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>
	<ca471dc205072813205fe3d89f@mail.gmail.com>
Message-ID: <8F4FFCC6-3F0F-493E-866A-2B772A739BD5@fuhm.net>


On Jul 28, 2005, at 4:20 PM, Guido van Rossum wrote:
> Managing users is especially important -- if a
> user is compromised (as has happened in the past for python.org users)
> the whole repository is compromised. Now this could happen to SF users
> too, but I'm not sure that we know all the tricks in the book to
> prevent attacks; SF has been doing this for years and that's an aspect
> of SF that I trust (I think I've heard that they have even modified
> their SSH server to be stricter).

If you use the fsfs storage mechanism for subversion, it is somewhat  
simpler to verify that the repository is not compromised. Each commit  
is represented as a separate file, and thus old commits are never  
modified. Only new files are appended to the directory. If you have a  
filesystem that allows "append-only" permissions on a directory, you  
can enforce this directly. Additionally, it is possible in your  
backup script to verify that only new files were added and nothing  
else changed.

Then at least you know how much you need to examine instead of having  
to treat the entire repository as possibly contaminated.

James

From chuckr at chuckr.org  Tue Jul 26 23:15:09 2005
From: chuckr at chuckr.org (Chuck Robey)
Date: Tue, 26 Jul 2005 17:15:09 -0400
Subject: [Python-Dev] installation of python on a Zaurus
In-Reply-To: <20050725130453.GA27192@panix.com>
References: <42E451E7.4000406@chuckr.org> <20050725130453.GA27192@panix.com>
Message-ID: <42E6A7DD.7040707@chuckr.org>

Aahz wrote:
> On Sun, Jul 24, 2005, Chuck Robey wrote:
> 
>>I'm trying to get Python installed on a Zaurus, running OpenBSD.  
> 
> 
> While python-dev can be a good place to get questions like this
> answered, many more people read comp.lang.python, and you should ask
> there, too.

Thanks ... I found my problem, once I'd put in enough prints into 
setup.py to look at what what happening (I do wish I knew how to use the 
python debugging features better than I do) and read the library code, I 
realized that it seemed to be finding the libraries by relying on the 
Linux habit of softlinking libraries like libtcl85.so.1.0 to 
libtcl85.so.  This isn't done on the zaurus (until I forced it for the 
tcl libraries), and clearing this, got all my python 2.4.1 installed. 
I've played a bit with graphics already. so I guess I did it right.

From barry at python.org  Fri Jul 29 00:30:44 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Jul 2005 18:30:44 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E93940.6080708@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
Message-ID: <1122589831.23775.10.camel@geddy.wooz.org>

On Thu, 2005-07-28 at 16:00, "Martin v. L?wis" wrote:
> I'd like to see the Python source be stored in Subversion instead
> of CVS

+1

> , and on python.org instead of sf.net. 

+0

I know that SF has promised svn access to projects for a long time now,
but I haven't heard anything from them in a long time.  It's listed
under their "Strategic Projects" but the last update to that news item
was back in April.  Question: do we wait for SF to make the service
available (after getting more up-to-date status and a realistic
timetable), or do we go straight to svn.python.org?

> This is for discussion on python-dev and eventual BDFL pronouncement;
> if you see a reason not to make such a change, or if you would prefer
> a different procedure, please speak up. Encouragement and support is
> welcome, as well :-)

Thanks for writing this PEP Martin!

> 1. Assign passwords for all current committers for use on svn.python.org.
>    User names on SF and svn.python.org should be identical, unless some
>    committer requests a different user name.

We've been going with firstname.lastname (with some exceptions -- hi
Aahz! :) for the current svn access.  Is it better to stay with that
convention or to maintain consistency with SF's CVS committer names? 
Maybe the latter for revision history consistency.

> 2. At the beginning of the migration, announce that the repository on
>    SourceForge closed.

We can probably play games with the various CVS hooks to disable all
checkins during this time.  We might also want to disable the u/i access
to CVS at the same time.

> 4. Convert the CVS repository into two subversion repositories,
>    one for distutils and one for Python.

Do we also want to split off nondist and encodings?  IWBNI the Python
source code proper weren't buried too deep in the directory structure. 
Note that we might want to provide different access permission to
different parts of the repository (but I think we can do that even if we
don't split those off into separate repos).

> As the repository format, fsfs should be used (requires Subversion 1.1).
> fsfs has the advantage of being more backup-friendly, as it allows to
> backup a repository incrementally, without requiring to run any dump
> commands.

Definitely +1 on fsfs.

Again, thanks Martin!
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050728/314c72e6/attachment.pgp

From barry at python.org  Fri Jul 29 00:36:11 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Jul 2005 18:36:11 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <ca471dc205072813205fe3d89f@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>
	<ca471dc205072813205fe3d89f@mail.gmail.com>
Message-ID: <1122590170.23775.16.camel@geddy.wooz.org>

On Thu, 2005-07-28 at 16:20, Guido van Rossum wrote:

> I hope we're correctly estimating the effort required to manage the
> server and the users. 

Yah, me too! ;)

We are building some experience with this though, having moved many of
the system files, and all of the web pages, to svn.  So far, the
management overhead has been almost nil (um, None :).  We'll have a bit
of ongoing work to add users, but the infrastructure team is also
building up some community knowledge about how to do that.

> Managing users is especially important -- if a
> user is compromised (as has happened in the past for python.org users)
> the whole repository is compromised. Now this could happen to SF users
> too, but I'm not sure that we know all the tricks in the book to
> prevent attacks; SF has been doing this for years and that's an aspect
> of SF that I trust (I think I've heard that they have even modified
> their SSH server to be stricter).

James has a very interesting idea for mitigating this.  Presumably
<heh>, we'll have backups of everything.  I'll feel better when we have
coverage from maybe 6 admins spanning as many timezones as possible.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050728/c39a7a63/attachment-0001.pgp

From barry at python.org  Fri Jul 29 00:37:42 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Jul 2005 18:37:42 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <8F4FFCC6-3F0F-493E-866A-2B772A739BD5@fuhm.net>
References: <42E93940.6080708@v.loewis.de>
	<ca471dc205072813205fe3d89f@mail.gmail.com>
	<8F4FFCC6-3F0F-493E-866A-2B772A739BD5@fuhm.net>
Message-ID: <1122590262.23767.18.camel@geddy.wooz.org>

On Thu, 2005-07-28 at 17:58, James Y Knight wrote:

> If you use the fsfs storage mechanism for subversion, it is somewhat  
> simpler to verify that the repository is not compromised. Each commit  
> is represented as a separate file, and thus old commits are never  
> modified. Only new files are appended to the directory. If you have a  
> filesystem that allows "append-only" permissions on a directory, you  
> can enforce this directly. Additionally, it is possible in your  
> backup script to verify that only new files were added and nothing  
> else changed.
> 
> Then at least you know how much you need to examine instead of having  
> to treat the entire repository as possibly contaminated.

Would it buy us any additional piece of mind to checksum the transaction
files as they're committed and store those checksums outside the
repository?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050728/4824ca33/attachment.pgp

From t-meyer at ihug.co.nz  Fri Jul 29 01:06:47 2005
From: t-meyer at ihug.co.nz (Tony Meyer)
Date: Fri, 29 Jul 2005 11:06:47 +1200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <ECBA357DDED63B4995F5C1F5CBE5B1E8036F9703@its-xchg4.massey.ac.nz>
Message-ID: <ECBA357DDED63B4995F5C1F5CBE5B1E801B0F816@its-xchg4.massey.ac.nz>

[...]
> Publish the Repositories
> ========================
[...]
> As an option, websvn (available
> e.g. from the Debian websvn package) could be provided.

Is there any reason that this should be an option, and not just done?  For
occasional source (particularly C source) lookups, I've found webcvs really
useful (especially when on a machine without cvs or ssh).  I presume that
I'm not alone here.

If there are issues with it (stability, security, whatever), then I could
understand making it optional, but otherwise I think it would be great if
the PEP just included it.

=Tony.Meyer


From t-meyer at ihug.co.nz  Fri Jul 29 01:10:02 2005
From: t-meyer at ihug.co.nz (Tony Meyer)
Date: Fri, 29 Jul 2005 11:10:02 +1200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <ECBA357DDED63B4995F5C1F5CBE5B1E8036F971F@its-xchg4.massey.ac.nz>
Message-ID: <ECBA357DDED63B4995F5C1F5CBE5B1E801DB03E4@its-xchg4.massey.ac.nz>

> Do we also want to split off nondist and encodings?  IWBNI 
> the Python source code proper weren't buried too deep in the 
> directory structure. 

+1

=Tony.Meyer


From bcannon at gmail.com  Fri Jul 29 01:28:05 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 28 Jul 2005 16:28:05 -0700
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122589831.23775.10.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de>
	<1122589831.23775.10.camel@geddy.wooz.org>
Message-ID: <bbaeab1005072816284118c52d@mail.gmail.com>

On 7/28/05, Barry Warsaw <barry at python.org> wrote:
> On Thu, 2005-07-28 at 16:00, "Martin v. L?wis" wrote:
> > I'd like to see the Python source be stored in Subversion instead
> > of CVS
> 
> +1
> 

+1 from me as well; single commit numbers for commits across multiple
files will be wonderful.

> > , and on python.org instead of sf.net.
> 
> +0
> 
> I know that SF has promised svn access to projects for a long time now,
> but I haven't heard anything from them in a long time.  It's listed
> under their "Strategic Projects" but the last update to that news item
> was back in April.  Question: do we wait for SF to make the service
> available (after getting more up-to-date status and a realistic
> timetable), or do we go straight to svn.python.org?
> 

I say forget SF and we move it.  Of course I won't be involved with
the migration so me saying this doesn't mean too much.  =)

>> 1. Assign passwords for all current committers for use on svn.python.org.
>>    User names on SF and svn.python.org should be identical, unless some
>>   committer requests a different user name.
>
>We've been going with firstname.lastname (with some exceptions -- hi
>Aahz! :) for the current svn access.  Is it better to stay with that
>convention or to maintain consistency with SF's CVS committer names?
>Maybe the latter for revision history consistency.

I say go with the first.last naming.  While this might put committer
names out of sync, we could keep a mapping of SF names to the new
names in developers.txt for easy referencing.  But it would be handy
to have actual name references since I know I don't always remember
who is whom on SF since some people go with nicks that are not based
on their name at all.

[SNIP]
> > 4. Convert the CVS repository into two subversion repositories,
> >    one for distutils and one for Python.
> 
> Do we also want to split off nondist and encodings?  IWBNI the Python
> source code proper weren't buried too deep in the directory structure.
> Note that we might want to provide different access permission to
> different parts of the repository (but I think we can do that even if we
> don't split those off into separate repos).
>

Seems like a reasonable thing.  Would make it easier for occasional
committers as well as people who check out the code just for
generating a patch.
 
-Brett

From fperez.net at gmail.com  Fri Jul 29 02:07:36 2005
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 28 Jul 2005 18:07:36 -0600
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
References: <42E93940.6080708@v.loewis.de>
Message-ID: <dcbs08$7b5$1@sea.gmane.org>

"Martin v. L?wis" wrote:

> Converting the CVS Repository
> =============================
> 
> The Python CVS repository contains two modules: distutils and
> python. Keeping them together will produce quite long repository
> URLs, so it is more convenient if the Python CVS and the distutils
> CVS are converted into two separate repositories.

If I understand things correctly, one project/one repo creates a 'hard' barrier
for moving code across projects (while retaining history, so done via an svn
command).  Is the 'long url' really the only argument for this, and is it
significant enough?  Instead of:

https://svn.python.org/python
https://svn.python.org/distutils

you could have

https://svn.python.org/main/python
https://svn.python.org/main/distutils

or something similar.  It's an extra few chars, and it would give a convenient
way to branch off pieces of the main code into their own subprojects in the
future if needed.

For more experimental things, you can always have other repos:

https://svn.python.org/someotherrepo/...

But maybe the issue of moving code isn't too important, I'm certainly no expert
on svn.

Cheers,

f


From lambacck at computer.org  Fri Jul 29 02:14:26 2005
From: lambacck at computer.org (Chris Lambacher)
Date: Thu, 28 Jul 2005 20:14:26 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <ca471dc205072813205fe3d89f@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>
	<ca471dc205072813205fe3d89f@mail.gmail.com>
Message-ID: <20050729001426.GA13636@computer.org>

I theory Subversion should allow you to be more secure.  CVS has a very
limited concept of security and for the most part you need to rely on SSH.
Subversion makes use of Apache as one of its server options.  Any
authentication method you can use in Apache 2 you can use for Subversion.
Once Apache does the authentication, Subversion allows fairly fine grained
access control.  SSL can be used for encrypting communication.

Note that there are sites like Sourceforge that do provide Subversion hosting
to open source projects.  I don't know enough about them to be able to
recommend any.

-Chris


On Thu, Jul 28, 2005 at 01:20:14PM -0700, Guido van Rossum wrote:
> On 7/28/05, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > I'd like to see the Python source be stored in Subversion instead
> > of CVS, and on python.org instead of sf.net. To facilitate discussion,
> > I have drafted a PEP describing the rationale for doing so, and
> > the technical procedure to be performed.
> 
> In principle I'm +1 on this (both aspects). I don't know enough to
> understand all the subtleties.
> 
> I hope we're correctly estimating the effort required to manage the
> server and the users. Managing users is especially important -- if a
> user is compromised (as has happened in the past for python.org users)
> the whole repository is compromised. Now this could happen to SF users
> too, but I'm not sure that we know all the tricks in the book to
> prevent attacks; SF has been doing this for years and that's an aspect
> of SF that I trust (I think I've heard that they have even modified
> their SSH server to be stricter).
> 
> -- 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/lambacck%40computer.org

From leif at ogre.com  Fri Jul 29 02:15:21 2005
From: leif at ogre.com (Leif Hedstrom)
Date: Thu, 28 Jul 2005 17:15:21 -0700
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E93940.6080708@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
Message-ID: <42E97519.6040101@ogre.com>

Martin v. L?wis wrote:

>Currently, access to Subversion on svn.python.org uses WebDAV over
>https, using basic authentication. For this to work, authorized
>users need to provide a password. This mechanism should be used,
>atleast initially, for the Python CVS as well, since various committers
>also have a username/password pair for the www SVN repository already.
>
>Alternatives to password-based access include:
>- Subversion over SSH, using SSH key pairs. This would require
>  to give committers accounts on the machine, which currently is
>  ruled out by the administration policy of svn.python.org.
>- Subversion over WebDAV, using SSL client certificates. This
>  would work, but would require to administrate a certificate
>  authority.
>  
>

I'm definitely positive to a migration to Subversion, but I'd be really 
concerned about using plain text authentication mechanisms. SSH 
obviously is much prefered, and clearly there are ways to limit the 
"accounts" on the svn.python.org, many other projects does this already 
for cvs. E.g

thor (17:11) 350/0 $ ssh -l 'username' cvs.mozilla.org

To use anonymous CVS install the latest version of CVS on your local 
machine.
Then set your CVSROOT environment variable to the following value:
        cvsuser at megalon:/cvsroot

Connection to cvs.mozilla.org closed.


We should have enough man powers to come up with some secure solution 
here :).

-- Leif


From tim.peters at gmail.com  Fri Jul 29 02:21:43 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 28 Jul 2005 20:21:43 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E93940.6080708@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
Message-ID: <1f7befae050728172161d4a9e8@mail.gmail.com>

[Martin v. L?wis]
> I'd like to see the Python source be stored in Subversion instead
> of CVS, and on python.org instead of sf.net. To facilitate discussion,
> I have drafted a PEP describing the rationale for doing so, and
> the technical procedure to be performed.
>
> This is for discussion on python-dev and eventual BDFL pronouncement;
> if you see a reason not to make such a change, or if you would prefer
> a different procedure, please speak up. Encouragement and support is
> welcome, as well :-)

Encouragement and support on SVN, undecided on moving to python.org
(don't know when SF intends to support SVN, don't have a feel for the
state of-- or propsects for ongoing --python.org volunteerism).

> ...
> The conversion should be done using cvs2svn utility, available e.g.
> in the cvs2svn Debian package. The command for converting the Python
> repository is
>
> cvs2svn -q --encoding=latin1 --force-branch=cnri-16-start
> --force-branch=descr-branch --force-branch=release152p1-patches
> --force-tag=r16b1 --fs-type=fsfs -s py.svn.new python/python
>
> The command to convert the distutils repository is
>
> cvs2svn -q --encoding=latin1 --fs-type=fsfs -s dist.svn.new python/distutils
> 
> Sample results of this conversion are available at
> 
> http://www.dcl.hpi.uni-potsdam.de/python/
> http://www.dcl.hpi.uni-potsdam.de/distutils/

I'm sending this to Jim Fulton because he did the conversion of Zope
Corp's code base to SVN.  Unfortunately, Jim will soon be out of touch
for several weeks.  Jim, do you have time to summarize the high bits
of the problems you hit?  IIRC, you didn't find any conversion script
at the time capable of doing the whole job as-is.  If that's wrong, it
would be good to know that too.

Other than that, I'd just like to see an explicit mention in the PEP
of a plan to preserve the pre-conversion CVS tarball forever.

From jeff at taupro.com  Fri Jul 29 02:56:03 2005
From: jeff at taupro.com (Jeff Rush)
Date: Thu, 28 Jul 2005 19:56:03 -0500
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1f7befae050728172161d4a9e8@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
Message-ID: <200507281956.03788.jeff@taupro.com>

On Thursday 28 July 2005 07:21 pm, Tim Peters wrote:
> [Martin v. L?wis]
>
> > The conversion should be done using cvs2svn utility, available e.g.
> > in the cvs2svn Debian package. The command for converting the Python
> > repository is

<snip>

> > Sample results of this conversion are available at
> >
> > http://www.dcl.hpi.uni-potsdam.de/python/
> > http://www.dcl.hpi.uni-potsdam.de/distutils/
>
> I'm sending this to Jim Fulton because he did the conversion of Zope
> Corp's code base to SVN.  Unfortunately, Jim will soon be out of touch
> for several weeks.  Jim, do you have time to summarize the high bits
> of the problems you hit?  IIRC, you didn't find any conversion script
> at the time capable of doing the whole job as-is.  If that's wrong, it
> would be good to know that too.

The conversion script isn't perfect and does fail on complex CVS arrangements 
or where there is extensive history to migate.  However it appears above that 
Martin has already tried the script out, with success.

BTW, re SSH access on python.org, using Apache's SSL support re https would 
provide as good of security without the risk of giving out shell accounts.  
SSL would encrypt the link and require a password or permit cert auth 
instead, same as SSH.  Cert admin needn't be hard if only a single server 
cert is used, with client passwords, instead of client certs.

-Jeff

From barry at python.org  Fri Jul 29 03:19:23 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Jul 2005 21:19:23 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E97519.6040101@ogre.com>
References: <42E93940.6080708@v.loewis.de>  <42E97519.6040101@ogre.com>
Message-ID: <1122599962.9671.3.camel@geddy.wooz.org>

On Thu, 2005-07-28 at 20:15, Leif Hedstrom wrote:

> I'm definitely positive to a migration to Subversion, but I'd be really 
> concerned about using plain text authentication mechanisms. 

We won't use plain text, but we may (or, we currently do) use basic auth
over ssl.  The security then is in the passwords, so we have to make
sure they're generated securely.

> We should have enough man powers to come up with some secure solution 
> here :).

Volunteers (i.e. those with actual free time to give on implementing any
solution) are definitely welcome.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050728/cb94f264/attachment.pgp

From bob at redivi.com  Fri Jul 29 03:30:45 2005
From: bob at redivi.com (Bob Ippolito)
Date: Thu, 28 Jul 2005 15:30:45 -1000
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122599962.9671.3.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de> <42E97519.6040101@ogre.com>
	<1122599962.9671.3.camel@geddy.wooz.org>
Message-ID: <95D0D6DF-8D5F-4D80-B04A-E761A242A0CC@redivi.com>


On Jul 28, 2005, at 3:19 PM, Barry Warsaw wrote:

> On Thu, 2005-07-28 at 20:15, Leif Hedstrom wrote:
>
>
>> I'm definitely positive to a migration to Subversion, but I'd be  
>> really
>> concerned about using plain text authentication mechanisms.
>>
>
> We won't use plain text, but we may (or, we currently do) use basic  
> auth
> over ssl.  The security then is in the passwords, so we have to make
> sure they're generated securely.

Users can generate their hashed password with the htpasswd command  
locally, and send those to the server.  That's what most subversion  
hosts seem to prefer.

-bob


From fperez.net at gmail.com  Fri Jul 29 03:30:24 2005
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 28 Jul 2005 19:30:24 -0600
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
Message-ID: <dcc0rg$g9l$1@sea.gmane.org>

Tim Peters wrote:

> [Martin v. L?wis]

>> The conversion should be done using cvs2svn utility, available e.g.
>> in the cvs2svn Debian package. The command for converting the Python
>> repository is

[...]
 
> I'm sending this to Jim Fulton because he did the conversion of Zope
> Corp's code base to SVN.  Unfortunately, Jim will soon be out of touch
> for several weeks.  Jim, do you have time to summarize the high bits
> of the problems you hit?  IIRC, you didn't find any conversion script
> at the time capable of doing the whole job as-is.  If that's wrong, it
> would be good to know that too.

If you hit any snags, you may be interested in contacting the admin for
scipy.org.  The scipy CVS repo choked cvs2svn pretty badly a while ago, but
recent efforts eventually prevailed.  This afternoon an email arrived from
him:

-------- Original Message --------
Subject: [SciPy-dev] SciPy CVS to Subversion migration
Date: Thu, 28 Jul 2005 20:02:59 -0500
From: Joe Cooper <joe at enthought.com>
Reply-To: SciPy Developers List <scipy-dev at scipy.net>
To: SciPy Dev List <scipy-dev at scipy.net>

Hi all,

The issues with converting our CVS repository to Subversion have been 
resolved, and so I'd like to make the switch tomorrow (Friday) afternoon.

[...]

------------------------------------------------------------

I know Joe was in contact with the SVN devs to work on this, so perhaps he's
using a patched version of cvs2svn, I simply don't know.  But I mention it in
case it proves useful to the python.org conversion.

cheers,

f


From tim.peters at gmail.com  Fri Jul 29 04:14:10 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 28 Jul 2005 22:14:10 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <200507281956.03788.jeff@taupro.com>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
	<200507281956.03788.jeff@taupro.com>
Message-ID: <1f7befae05072819142c36e610@mail.gmail.com>

[Jeff Rush]
> The conversion script isn't perfect and does fail on complex CVS
> arrangements or where there is extensive history to migate.  However it
> appears above that Martin has already tried the script out, with success.

I'd still like to hear from Jim, as I don't believe all serious
problems were identified by eyeball at once.  That said, the Python
project has made relatively very little use of complex (for CVS)
concepts like branching, but in Zopeland it wasn't unusual, over long
stretches, for someone to make a new branch every day.

Ah, before I forget, "single repository" has worked very well for Zope
(which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
projects):

    http://svn.zope.org/

Long URLs don't really get in the way in practice (rarely a need to
type one after initial checkout; even "svn switch" is usually just a
tail-end cmdline edit starting from a copy+paste of "svn info"
output).

From barry at python.org  Fri Jul 29 04:48:43 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Jul 2005 22:48:43 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1f7befae05072819142c36e610@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
	<200507281956.03788.jeff@taupro.com>
	<1f7befae05072819142c36e610@mail.gmail.com>
Message-ID: <1122605323.9670.11.camel@geddy.wooz.org>

On Thu, 2005-07-28 at 22:14, Tim Peters wrote:

> Ah, before I forget, "single repository" has worked very well for Zope
> (which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
> projects):
> 
>     http://svn.zope.org/
> 
> Long URLs don't really get in the way in practice (rarely a need to
> type one after initial checkout; even "svn switch" is usually just a
> tail-end cmdline edit starting from a copy+paste of "svn info"
> output).

It depends.  In my use of svn, I do a lot of cross-branch merging and
repo-side tagging.  Those are done with urls and in those cases, long
urls can suck.  But we may not do a ton of that with the Python project,
and besides it might not be important enough to split the directories.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050728/4e0dccc9/attachment.pgp

From tim.peters at gmail.com  Fri Jul 29 04:59:50 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 28 Jul 2005 22:59:50 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122605323.9670.11.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
	<200507281956.03788.jeff@taupro.com>
	<1f7befae05072819142c36e610@mail.gmail.com>
	<1122605323.9670.11.camel@geddy.wooz.org>
Message-ID: <1f7befae0507281959abc2a7c@mail.gmail.com>

[Tim]
>> Ah, before I forget, "single repository" has worked very well for Zope
>> (which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
>> projects):
>>
>>     http://svn.zope.org/
>>
>> Long URLs don't really get in the way in practice (rarely a need to
>> type one after initial checkout; even "svn switch" is usually just a
>> tail-end cmdline edit starting from a copy+paste of "svn info"
>> output).
 
[Barry]
> It depends.  In my use of svn, I do a lot of cross-branch merging and
> repo-side tagging.

Yup, me too -- between the two of us, we don't have enough fingers to
count how many trunks, branches, and tags of ZODB and Zope I have to
fiddle with.

> Those are done with urls and in those cases, long urls can suck.

They're all still copy, paste, tail-edit for me, and-- indeed!
--having them all in the same repository is what makes just-the-tail
editing possible.  Merges I do from the cmdline, but repo-side tagging
I do with the TortoiseSVN GUI, and the latter gives
easy-to-copy/paste/edit URL fields.  So switch to Windows for that
part ;-)

> But we may not do a ton of that with the Python project,
> and besides it might not be important enough to split the directories.

Ya, in Python we make a branch about once per release, + once per 5
years when Jeremy underestimates how long it will take to finish a
crusade <wink>.

From aahz at pythoncraft.com  Fri Jul 29 05:17:31 2005
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 28 Jul 2005 20:17:31 -0700
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122605323.9670.11.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
	<200507281956.03788.jeff@taupro.com>
	<1f7befae05072819142c36e610@mail.gmail.com>
	<1122605323.9670.11.camel@geddy.wooz.org>
Message-ID: <20050729031731.GA21385@panix.com>

On Thu, Jul 28, 2005, Barry Warsaw wrote:
> On Thu, 2005-07-28 at 22:14, Tim Peters wrote:
>> 
>> Ah, before I forget, "single repository" has worked very well for Zope
>> (which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
>> projects):
>> 
>>     http://svn.zope.org/
>> 
>> Long URLs don't really get in the way in practice (rarely a need to
>> type one after initial checkout; even "svn switch" is usually just a
>> tail-end cmdline edit starting from a copy+paste of "svn info"
>> output).
> 
> It depends.  In my use of svn, I do a lot of cross-branch merging and
> repo-side tagging.  Those are done with urls and in those cases, long
> urls can suck.  But we may not do a ton of that with the Python project,
> and besides it might not be important enough to split the directories.

Why can't you write a Python script to generate the URLs?  <0.3 wink>
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.

From barry at python.org  Fri Jul 29 05:27:53 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Jul 2005 23:27:53 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1f7befae0507281959abc2a7c@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
	<200507281956.03788.jeff@taupro.com>
	<1f7befae05072819142c36e610@mail.gmail.com>
	<1122605323.9670.11.camel@geddy.wooz.org>
	<1f7befae0507281959abc2a7c@mail.gmail.com>
Message-ID: <1122607673.9665.38.camel@geddy.wooz.org>

On Thu, 2005-07-28 at 22:59, Tim Peters wrote:

> Yup, me too -- between the two of us, we don't have enough fingers to
> count how many trunks, branches, and tags of ZODB and Zope I have to
> fiddle with.

I have a small inkling of your pain.

> They're all still copy, paste, tail-edit for me, and-- indeed!
> --having them all in the same repository is what makes just-the-tail
> editing possible.  

Good point!

> Ya, in Python we make a branch about once per release, + once per 5
> years when Jeremy underestimates how long it will take to finish a
> crusade <wink>.

So are you saying that moving to svn will let us do more long lived
branches?  Yay!

-B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050728/307de024/attachment.pgp

From martin at v.loewis.de  Fri Jul 29 06:35:56 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 06:35:56 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122589831.23775.10.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de>
	<1122589831.23775.10.camel@geddy.wooz.org>
Message-ID: <42E9B22C.2030502@v.loewis.de>

Barry Warsaw wrote:
 > I know that SF has promised svn access to projects for a long time now,
> but I haven't heard anything from them in a long time.  It's listed
> under their "Strategic Projects" but the last update to that news item
> was back in April.  Question: do we wait for SF to make the service
> available (after getting more up-to-date status and a realistic
> timetable), or do we go straight to svn.python.org?

My proposal is to go straight to svn.python.org, for two reasons:
- It might well be 2006 before they update the status and provide
  a realistic timetable. It's not that I lost faith into SF, but
  they seem to be continually overworked (as anybody), so anything
  that is not *really* essential to the operation of the service
  (such as support for subversion) has to wait "until we have
  time" -- which means it has to wait forever. Remember the plan
  to provide shell access to the project admins on the CVS server?
- They currently have a separate anonymous access for CVS which
  is behind the real CVS, for load sharing reasons. They also had
  severe performance issues in the past. It might be that we
  also get performance problems, but we only need to support a
  single project (or two if you count pydotorg) on Subversion,
  not thousands of them. So our load evolution is much more
  predictable.

>>1. Assign passwords for all current committers for use on svn.python.org.
>>   User names on SF and svn.python.org should be identical, unless some
>>   committer requests a different user name.
> 
> 
> We've been going with firstname.lastname (with some exceptions -- hi
> Aahz! :) for the current svn access.  Is it better to stay with that
> convention or to maintain consistency with SF's CVS committer names? 
> Maybe the latter for revision history consistency.

It's also a convenience issue, and has social aspects. For example,
firstname.lastname does not work quite well for me, either
(martin.v.loewis or martin.von.loewis would work better; likewise
guido.van.rossum?), other users prefer not to use their "true"
real name (e.g. tim_one vs. tim.peters).

Another issue is password assignment - currently, users cannot choose
their passwords on svn.python.org, right?

> We can probably play games with the various CVS hooks to disable all
> checkins during this time.  We might also want to disable the u/i access
> to CVS at the same time.

That should be tested in advance, of course.

>>4. Convert the CVS repository into two subversion repositories,
>>   one for distutils and one for Python.
> 
> 
> Do we also want to split off nondist and encodings?

Well, encodings is empty right now, so that might be a good idea.
Technically, I would just move the files in the CVS repository before
conversion.

As for nondist: how precisely would you do that? Make it a separate
repository? If so, where? I could envision a "/projects" repository,
that has the current nondist.

> Note that we might want to provide different access permission to
> different parts of the repository (but I think we can do that even if we
> don't split those off into separate repos).

I don't know how cvs2svn supports it, but one option would be to
revert the trunk/ structure in /projects, so you get

http://www.python.org/projects/peps/trunk
http://www.python.org/projects/peps/tags
http://www.python.org/projects/peps/branches
http://www.python.org/projects/sandbox/trunk
http://www.python.org/projects/sandbox/tags
http://www.python.org/projects/sandbox/branches

Then you could give different access to peps and to sandbox.
Perhaps there isn't even a need for tags/branches on PEPs? Or
we put everything in nondist into /projects, and then put
tags + branches as siblings (so only people with write access
to tags could create them)?

Regards,
Martin

From fdrake at acm.org  Fri Jul 29 06:41:20 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 29 Jul 2005 00:41:20 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <dcbs08$7b5$1@sea.gmane.org>
References: <42E93940.6080708@v.loewis.de> <dcbs08$7b5$1@sea.gmane.org>
Message-ID: <200507290041.20634.fdrake@acm.org>

On Thursday 28 July 2005 20:07, Fernando Perez wrote:
 > or something similar.  It's an extra few chars, and it would give a
 > convenient way to branch off pieces of the main code into their own
 > subprojects in the future if needed.

More interestingly, keeping it in a single repository makes it easier to merge 
projects, or parts of projects, together, without losing the history.  This 
would be useful when developing packages that may be considered for the 
standard library, but which also need to continue separate releases to 
support older versions of Python.  We've found it very handy to keep multiple 
projects in a single repository for zope.org.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From martin at v.loewis.de  Fri Jul 29 06:44:34 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 06:44:34 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <ca471dc205072813205fe3d89f@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>
	<ca471dc205072813205fe3d89f@mail.gmail.com>
Message-ID: <42E9B432.9010406@v.loewis.de>

Guido van Rossum wrote:
> I hope we're correctly estimating the effort required to manage the
> server and the users. Managing users is especially important -- if a
> user is compromised (as has happened in the past for python.org users)
> the whole repository is compromised. Now this could happen to SF users
> too, but I'm not sure that we know all the tricks in the book to
> prevent attacks; SF has been doing this for years and that's an aspect
> of SF that I trust (I think I've heard that they have even modified
> their SSH server to be stricter).

There are three issues that I see:
- management of access control. This is actually something that we
  do on SF as well; if the pydotorg admins get overloaded, I'm sure
  the current projects/python admins would be willing to help there.
- assignment of passwords. This I don't like about the current
  pydotorg setup - there should be a way to chose your own password;
  perhaps without involving an administrator.
  I could imagine a web form for password change, and administrator
  interaction in case of a lost password.
- compromised passwords. The only tricky question then is: was the
  repository altered? Fortunately, for Subversion, there should be
  an easy way to tell: in fsfs, files never change (only new files
  are added). So we could generate md5sums of all files in the
  repository, and download these to an offsite place. If the md5sum
  of an immutable file changes, we were compromised (there are,
  of course, a few files that do change regularly).
  Of course, we also need regular backups of the entire data
  so we can restore them if they got compromised.

Regards,
Martin

From kbk at shore.net  Fri Jul 29 06:47:31 2005
From: kbk at shore.net (Kurt B. Kaiser)
Date: Fri, 29 Jul 2005 00:47:31 -0400 (EDT)
Subject: [Python-Dev] Weekly Python Patch/Bug Summary
Message-ID: <200507290447.j6T4lVHG006970@bayview.thirdcreek.com>

Patch / Bug Summary
___________________

Patches :  357 open ( +7) /  2885 closed ( +3) /  3242 total (+10)
Bugs    :  898 open ( +9) /  5144 closed ( +3) /  6042 total (+12)
RFE     :  191 open ( +2) /   178 closed ( +0) /   369 total ( +2)

New / Reopened Patches
______________________

shutil.copytree() quits too soon after an error.  (2005-07-21)
       http://python.org/sf/1242454  opened by  Dale Wilson

bltinmodule.c whitespace normalization  (2005-07-21)
       http://python.org/sf/1242579  opened by  Ruslan Spivak

repair typos  (2005-07-22)
CLOSED http://python.org/sf/1243081  opened by  George Yoshida

Faster output if message already has a boundary  (2005-07-23)
       http://python.org/sf/1243654  opened by  L. Peter Deutsch

httplib gzip support  (2005-07-23)
       http://python.org/sf/1243678  opened by  Moonz

Big speedup in email message parsing  (2005-07-23)
       http://python.org/sf/1243730  opened by  L. Peter Deutsch

Patch for (Doc) #1243553  (2005-07-24)
       http://python.org/sf/1243910  opened by  Peter van Kampen

expat binding for XML_ParserReset (Bug #1208730)  (2005-07-24)
       http://python.org/sf/1244208  opened by  John Eikenberry

Enable os.startfile and webbrowser.WindowsDefault on Cygwin  (2005-07-25)
       http://python.org/sf/1244861  opened by  Michael Hoffman

hide tests from TestProgram  (2005-07-25)
       http://python.org/sf/1244929  opened by  Eric Huss

Encoding alias "unicode-1-1-utf-7"  (2005-07-26)
       http://python.org/sf/1245379  opened by  Oren Tirosh

weaklist  (2001-11-30)
       http://python.org/sf/487738  reopened by  fdrake

Patches Closed
______________

optparse documentation bug fixes  (2005-05-18)
       http://python.org/sf/1204347  closed by  gward

repair typos  (2005-07-22)
       http://python.org/sf/1243081  closed by  birkenfeld

fileinput.py fixed clobbering behavior and added encodings  (2004-10-15)
       http://python.org/sf/1048075  closed by  cconnett

Allow use of embedded Tcl without requiring Tk  (2004-01-02)
       http://python.org/sf/869468  closed by  gvanrossum

New / Reopened Bugs
___________________

list(obj) can swallow KeyboardInterrupt  (2005-07-22)
       http://python.org/sf/1242657  opened by  Steve Alexander

Incorrect documentation of re.UNICODE  (2005-07-22)
       http://python.org/sf/1243192  opened by  nhaldimann

Misuse of "it's"    (2005-07-22)
CLOSED http://python.org/sf/1243288  opened by  Joanne Bogart

pydoc on cgi.escape lacks info that are in www docs  (2005-07-23)
       http://python.org/sf/1243553  opened by  Nikos Kouremenos

Python function/method/constant names as HTML-tag IDs  (2005-07-24)
       http://python.org/sf/1243945  opened by  Chad Miller

2.4.1 build fails on OpenBSD 3.7  (2005-07-25)
       http://python.org/sf/1244610  opened by  L. Peter Deutsch

logging module needs to that it changed in 2.4  (2005-07-25)
       http://python.org/sf/1244683  opened by  Alan

Segfault in Python interpreter 2.3.5  (2005-07-25)
       http://python.org/sf/1244864  opened by  Evil Mr Henry

Time module is missing inverse of gmtime()  (2005-07-26)
       http://python.org/sf/1245224  opened by  Jeremy Fincher

log() on a big number fails on powerpc64  (2005-07-26)
       http://python.org/sf/1245381  opened by  Jiri Dluhos

Segmentation fault when importing expat from xml.parser  (2005-07-28)
       http://python.org/sf/1246405  opened by  Jean-Pierre

line numbers off by 1  (2005-07-27)
       http://python.org/sf/1246473  opened by  Brett Cannon

failure to build RPM on rhel 3  (2005-07-28)
       http://python.org/sf/1246900  opened by  Patrick Wagstrom

Bugs Closed
___________

Misuse of "it's"    (2005-07-22)
       http://python.org/sf/1243288  closed by  birkenfeld

ioctl has problem with -ive request codes  (2005-07-01)
       http://python.org/sf/1231069  closed by  mwh

ioctl has problems on 64 bit machines  (2005-01-31)
       http://python.org/sf/1112949  closed by  birkenfeld


From martin at v.loewis.de  Fri Jul 29 06:48:35 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 06:48:35 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <ECBA357DDED63B4995F5C1F5CBE5B1E801B0F816@its-xchg4.massey.ac.nz>
References: <ECBA357DDED63B4995F5C1F5CBE5B1E801B0F816@its-xchg4.massey.ac.nz>
Message-ID: <42E9B523.1040605@v.loewis.de>

Tony Meyer wrote:
> Is there any reason that this should be an option, and not just done?

Certainly: it's administrator load, which in turn is volunteer time.

> For
> occasional source (particularly C source) lookups, I've found webcvs really
> useful (especially when on a machine without cvs or ssh).  I presume that
> I'm not alone here.

Of course, so if there is a volunteer, to actually set it up, it should
be done. For the PEP itself, somebody would have to contribute precise
instructions how to setup websvn (what URLs, how does the Apache
configuration read, etc).

> If there are issues with it (stability, security, whatever), then I could
> understand making it optional, but otherwise I think it would be great if
> the PEP just included it.

There are security issues in the setup if you want to have non-public
repositories (which then shouldn't be public through websvn, either).
The pydotorg repository itself is non-public, but I don't know whether
this would be an issue.

Regards,
Martin

From petrilli at gmail.com  Fri Jul 29 06:50:16 2005
From: petrilli at gmail.com (Christopher Petrilli)
Date: Fri, 29 Jul 2005 00:50:16 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <200507290041.20634.fdrake@acm.org>
References: <42E93940.6080708@v.loewis.de> <dcbs08$7b5$1@sea.gmane.org>
	<200507290041.20634.fdrake@acm.org>
Message-ID: <59d991c4050728215038182832@mail.gmail.com>

On 7/29/05, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
> On Thursday 28 July 2005 20:07, Fernando Perez wrote:
>  > or something similar.  It's an extra few chars, and it would give a
>  > convenient way to branch off pieces of the main code into their own
>  > subprojects in the future if needed.
> 
> More interestingly, keeping it in a single repository makes it easier to merge
> projects, or parts of projects, together, without losing the history.  This
> would be useful when developing packages that may be considered for the
> standard library, but which also need to continue separate releases to
> support older versions of Python.  We've found it very handy to keep multiple
> projects in a single repository for zope.org.

I thought I would chime in on this with some more experience.  We use
SVN (migated from CVS about 2 years ago) for everything, and we keep
it all in one repository (even though there's several "products") for
exactly this reason.  The major "downside" that I, and some others,
find is changeset explosion.  When you start getting into 5 digit
changeset numbers it can become a bit unwieldy to remember to type
them all, but otherwise it works well.

We also moved from BerkeleyDB-based to fsfs recently, and it seems to
have fixed some intermittent problems we had had in the past.

Another thing to look at would be Trac, which we are in the process of
moving to from the horrendous nightmare of Bugzilla.  It's integration
with SVN as well as Wiki is quite amazing.

Chris
-- 
| Christopher Petrilli
| petrilli at gmail.com

From martin at v.loewis.de  Fri Jul 29 06:57:03 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 06:57:03 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <200507290041.20634.fdrake@acm.org>
References: <42E93940.6080708@v.loewis.de> <dcbs08$7b5$1@sea.gmane.org>
	<200507290041.20634.fdrake@acm.org>
Message-ID: <42E9B71F.9030905@v.loewis.de>

Fred L. Drake, Jr. wrote:
> More interestingly, keeping it in a single repository makes it easier to merge 
> projects, or parts of projects, together, without losing the history.  This 
> would be useful when developing packages that may be considered for the 
> standard library, but which also need to continue separate releases to 
> support older versions of Python.  We've found it very handy to keep multiple 
> projects in a single repository for zope.org.

So do you use project/trunk or trunk/project? If the former, I would
need to get instructions on how to do the conversion from CVS.

Regards,
Martin

From martin at v.loewis.de  Fri Jul 29 07:00:06 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 07:00:06 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122599962.9671.3.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de> <42E97519.6040101@ogre.com>
	<1122599962.9671.3.camel@geddy.wooz.org>
Message-ID: <42E9B7D6.6010708@v.loewis.de>

Barry Warsaw wrote:
> We won't use plain text, but we may (or, we currently do) use basic auth
> over ssl.  The security then is in the passwords, so we have to make
> sure they're generated securely.

That (sort of) *is* plain text passwords. Somebody who took over
svn.python.org can get the password. In public-key or digest
authentication, this won't be possible.

Regards,
Martin

From martin at v.loewis.de  Fri Jul 29 07:11:05 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 07:11:05 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1f7befae05072819142c36e610@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>	<1f7befae050728172161d4a9e8@mail.gmail.com>	<200507281956.03788.jeff@taupro.com>
	<1f7befae05072819142c36e610@mail.gmail.com>
Message-ID: <42E9BA69.3070704@v.loewis.de>

Tim Peters wrote:
> Ah, before I forget, "single repository" has worked very well for Zope
> (which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
> projects):
> 
>     http://svn.zope.org/
> 
> Long URLs don't really get in the way in practice (rarely a need to
> type one after initial checkout; even "svn switch" is usually just a
> tail-end cmdline edit starting from a copy+paste of "svn info"
> output).

That would indeed give conversion problems: cvs2svn automatically
generates tags/trunk/branches in the root, with the original CVS
modules below; there is a single space for tags and branches
(as is in the original CVS repository).

I would see two possible conversion procedures:
1. convert the modules one-by-one, adding to the same repository.
   I.e. python would get all the small revision numbers, then
   peps, then sandbox, and so on. Cross-module tags would not
   be supported (but likely don't exist in the first place),
   and the revision number would not increase in historical order.
2. convert the entire CVS, then rearrange things through
   svn move. This would be tedious to do (atleast for tags/branches),
   and it would cause all files to be renamed right from the
   scratch (some svn clients fail to display history past moves).

So for all who would prefer to see a single repository, could
somebody please
1. state how precisely the repository should be organized
   (with exact URLs on svn.python.org - eg. which of the
   non-dist directories becomes toplevel, which ones
   get their own tags/branches/trunk, etc).
2. state how the conversion should be performed

Regards,
Martin

From fperez.net at gmail.com  Fri Jul 29 08:12:41 2005
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 29 Jul 2005 00:12:41 -0600
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
References: <42E93940.6080708@v.loewis.de> <dcbs08$7b5$1@sea.gmane.org>
	<200507290041.20634.fdrake@acm.org> <42E9B71F.9030905@v.loewis.de>
Message-ID: <dcchcp$ck8$1@sea.gmane.org>

"Martin v. L?wis" wrote:

> Fred L. Drake, Jr. wrote:
>> More interestingly, keeping it in a single repository makes it easier to
>> merge
>> projects, or parts of projects, together, without losing the history.  This
>> would be useful when developing packages that may be considered for the
>> standard library, but which also need to continue separate releases to
>> support older versions of Python.  We've found it very handy to keep multiple
>> projects in a single repository for zope.org.
> 
> So do you use project/trunk or trunk/project? If the former, I would
> need to get instructions on how to do the conversion from CVS.

For ipython, which recently went through cvs2svn, I found that moving over to a
project/trunk structure was a few minutes worth of work.  Since svn has moving
commands, it was just a matter of making the extra project/ directory and
moving things one level down the hierarchy.  Even if cvs2svn doesn't quite
create things the way you want them in the long run, svn is flexible enough
that a few manual tweaks should be quite easy to perform.

Cheers,

f


From mwh at python.net  Fri Jul 29 11:47:27 2005
From: mwh at python.net (Michael Hudson)
Date: Fri, 29 Jul 2005 10:47:27 +0100
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E93940.6080708@v.loewis.de> (
	=?iso-8859-1?q?Martin_v._L=F6wis's_message_of?= "Thu,
	28 Jul 2005 22:00:00 +0200")
References: <42E93940.6080708@v.loewis.de>
Message-ID: <2mk6ja0wr4.fsf@starship.python.net>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> - Subversion over SSH, using SSH key pairs. This would require
>   to give committers accounts on the machine, which currently is
>   ruled out by the administration policy of svn.python.org.

Would it work/how much risk would it be to create accounts with shell
/bin/false?

Cheers,
mwh
(still faintly bothered by ~/.subversion/auth/svn.simple/*...)

-- 
  If trees could scream, would we be so cavalier about cutting them
  down? We might, if they screamed all the time, for no good reason.
                                                        -- Jack Handey

From mal at egenix.com  Fri Jul 29 12:34:02 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 29 Jul 2005 12:34:02 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E93940.6080708@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
Message-ID: <42EA061A.9040609@egenix.com>

Martin v. L?wis wrote:
> I'd like to see the Python source be stored in Subversion instead
> of CVS, 

+1

> and on python.org instead of sf.net. To facilitate discussion,
> I have drafted a PEP describing the rationale for doing so, and
> the technical procedure to be performed.

Not sure about the move to svn.python.org. This would
bind additional developer resources for doing administration
work.

If SF is such a show-stopper, would it be reasonable to
look for managed alternatives, such as eg. CollabNet (who
funded Subversion development) ?

Perhaps we could get a good deal from them given that the
PSF is a non-profit organization. Greg Stein could probably
provide contacts to the right people to talk to.

http://www.collab.net/products/team_edition/index.html

Just an idea,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 29 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From jim at zope.com  Fri Jul 29 15:17:46 2005
From: jim at zope.com (Jim Fulton)
Date: Fri, 29 Jul 2005 09:17:46 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1f7befae050728172161d4a9e8@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
Message-ID: <42EA2C7A.7000300@zope.com>

Tim Peters wrote:
...
> I'm sending this to Jim Fulton because he did the conversion of Zope
> Corp's code base to SVN.  Unfortunately, Jim will soon be out of touch
> for several weeks.  Jim, do you have time to summarize the high bits
> of the problems you hit?  IIRC, you didn't find any conversion script
> at the time capable of doing the whole job as-is.  If that's wrong, it
> would be good to know that too.

I had two problems, one of which was zope specific:

1. We were making extensive use of symbolic links to share packages
    among various Zope projects.  This requires special care and
    was the main reason I wrote my own scrips.

    I don't expect that this would be an issue for Python.

2. I initially tried to conver our entire repository, including all
    branches.  This would have taken days.  I finally decided to just
    convert our trunk, which took several hours.  The main time
    sink was in the load step of the conversion process.

    I suspect that much of the time hit was due to the Berkely DB
    back end.  I think I've heard that the file-system-based back end
    is much faster in general.

We're using the BDB back end because that's all that was available
at the time we converted.  Every few weeks, the database gets wedged
and I have to do a recovery operation. Every few months, the machine gets
wedged and required a reboot. I'm pretty sure the later is due to locking
issues.  I definately recommend the file-system back-end, even though I
haven't tried it myself.  I haven't had the time to do the conversion
myself. :(

I'll also say that, on balance, I'm *very* *very* happy with subversion.
I recommend it highly.

> Other than that, I'd just like to see an explicit mention in the PEP
> of a plan to preserve the pre-conversion CVS tarball forever.

+1

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From jim at zope.com  Fri Jul 29 15:18:57 2005
From: jim at zope.com (Jim Fulton)
Date: Fri, 29 Jul 2005 09:18:57 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1f7befae05072819142c36e610@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de>	
	<1f7befae050728172161d4a9e8@mail.gmail.com>	
	<200507281956.03788.jeff@taupro.com>
	<1f7befae05072819142c36e610@mail.gmail.com>
Message-ID: <42EA2CC1.6000809@zope.com>

Tim Peters wrote:
> [Jeff Rush]
> 
>>The conversion script isn't perfect and does fail on complex CVS
>>arrangements or where there is extensive history to migate.  However it
>>appears above that Martin has already tried the script out, with success.
> 
> 
> I'd still like to hear from Jim, as I don't believe all serious
> problems were identified by eyeball at once. 

I'm not aware of any errors in the conversion.

...

> Ah, before I forget, "single repository" has worked very well for Zope

Yup.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From jim at zope.com  Fri Jul 29 15:28:05 2005
From: jim at zope.com (Jim Fulton)
Date: Fri, 29 Jul 2005 09:28:05 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E9BA69.3070704@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>	<1f7befae050728172161d4a9e8@mail.gmail.com>	<200507281956.03788.jeff@taupro.com>
	<1f7befae05072819142c36e610@mail.gmail.com>
	<42E9BA69.3070704@v.loewis.de>
Message-ID: <42EA2EE5.3000502@zope.com>

Martin v. L?wis wrote:
> Tim Peters wrote:
> 
>>Ah, before I forget, "single repository" has worked very well for Zope
>>(which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
>>projects):
>>
>>    http://svn.zope.org/
>>
>>Long URLs don't really get in the way in practice (rarely a need to
>>type one after initial checkout; even "svn switch" is usually just a
>>tail-end cmdline edit starting from a copy+paste of "svn info"
>>output).
> 
> 
> That would indeed give conversion problems:

Nah

 > cvs2svn automatically
> generates tags/trunk/branches in the root, with the original CVS
> modules below; there is a single space for tags and branches
> (as is in the original CVS repository).
> 
> I would see two possible conversion procedures:
> 1. convert the modules one-by-one, adding to the same repository.
>    I.e. python would get all the small revision numbers, then
>    peps, then sandbox, and so on. Cross-module tags would not
>    be supported (but likely don't exist in the first place),
>    and the revision number would not increase in historical order.
> 2. convert the entire CVS, then rearrange things through
>    svn move. This would be tedious to do (atleast for tags/branches),
>    and it would cause all files to be renamed right from the
>    scratch (some svn clients fail to display history past moves).

You reminded me of another reason why I used a custom conversion script.
:)

I did convert projects individually.  I told cvs2svn to just create dump
files.  I then used svnload to load the dump files myself so that
I could make each project a top-level directory with it's own
trunk, branches and tags.

I'd be happy to share my scrips, although there's nothing all that
complicated about them.

> So for all who would prefer to see a single repository, could
> somebody please
> 1. state how precisely the repository should be organized
>    (with exact URLs on svn.python.org - eg. which of the
>    non-dist directories becomes toplevel, which ones
>    get their own tags/branches/trunk, etc).

I'm not close enough to the Python repo to offer much
of an opinion other than:

- IMO, a single repository is good

- The repository should be orgabized by "projects",
   where separate projects reflect more or less independent
   development efforts with their own teams and schedules.
   (Maybe Python doesn't have many of these.)

> 2. state how the conversion should be performed

Once you decide what the projects are, I suggest
converting each project separately.  I'd be happy to
share my scrips and experenice, although, as Tim noted
I'll be off-line for two or three weeks starting in the
next few days.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From fdrake at acm.org  Fri Jul 29 15:38:51 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 29 Jul 2005 09:38:51 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA061A.9040609@egenix.com>
References: <42E93940.6080708@v.loewis.de> <42EA061A.9040609@egenix.com>
Message-ID: <200507290938.52072.fdrake@acm.org>

On Friday 29 July 2005 06:34, M.-A. Lemburg wrote:
 > If SF is such a show-stopper, would it be reasonable to
 > look for managed alternatives, such as eg. CollabNet (who
 > funded Subversion development) ?

docutils has been using berlios.de for Subversion; that might be a reasonable 
option.  I'm not sure if there are any political issues about that, but I 
think everyone actively developing on that project has been happy with the 
move.  (Only the berlios.de Subversion is being used; everything else remains 
at SourceForge IIRC.)


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From fdrake at acm.org  Fri Jul 29 15:53:16 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 29 Jul 2005 09:53:16 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <dcchcp$ck8$1@sea.gmane.org>
References: <42E93940.6080708@v.loewis.de> <42E9B71F.9030905@v.loewis.de>
	<dcchcp$ck8$1@sea.gmane.org>
Message-ID: <200507290953.16958.fdrake@acm.org>

Martin v. L?wis wrote:
 > So do you use project/trunk or trunk/project? If the former, I would
 > need to get instructions on how to do the conversion from CVS.

project/trunk/

On Friday 29 July 2005 02:12, Fernando Perez wrote:
 > For ipython, which recently went through cvs2svn, I found that moving over
 > to a project/trunk structure was a few minutes worth of work.  Since svn
 > has moving commands, it was just a matter of making the extra project/
 > directory and moving things one level down the hierarchy.  Even if cvs2svn
 > doesn't quite create things the way you want them in the long run, svn is
 > flexible enough that a few manual tweaks should be quite easy to perform.

Yes, this will work.  I vaguely recall that Jim converted the zope.org 
repository one project at a time, so that made it easier to keep them 
separate.  We didn't decommission the CVS entirely, though; Zope 2.7 is still 
maintained in CVS since we didn't want to risk worrying about the branch 
structure too much; cvs2svn still had a few issues with the complex branch 
structure combined with the use of symlinks within the repository (one of the 
reasons we were so keen to move to Subversion).

I'm sure Jim can provide more details of what he had to do; I was only 
slightly involved in the discussions.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From skip at pobox.com  Fri Jul 29 17:06:46 2005
From: skip at pobox.com (skip@pobox.com)
Date: Fri, 29 Jul 2005 10:06:46 -0500
Subject: [Python-Dev] math.fabs redundant?
Message-ID: <17130.17926.863069.507314@montanaro.dyndns.org>

Why does math have an fabs function?  Both it and the abs builtin function
wind up calling fabs() for floats.  abs() is faster to boot.

Skip

From fdrake at acm.org  Fri Jul 29 17:30:10 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 29 Jul 2005 11:30:10 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA2C7A.7000300@zope.com>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
	<42EA2C7A.7000300@zope.com>
Message-ID: <200507291130.10316.fdrake@acm.org>

On Friday 29 July 2005 09:17, Jim Fulton wrote:
 > 1. We were making extensive use of symbolic links to share packages
 >     among various Zope projects.  This requires special care and
 >     was the main reason I wrote my own scrips.
 >
 >     I don't expect that this would be an issue for Python.

I know of three symlinks in the Python repository, all from the distutils 
project.  There's one for the package and one for each of the documents.

 > 2. I initially tried to conver our entire repository, including all
 >     branches.  This would have taken days.  I finally decided to just
 >     convert our trunk, which took several hours.  The main time
 >     sink was in the load step of the conversion process.

This might be a possibility for Python as well, though we have a much less 
complex branching structure, so the conversion may not be so difficult.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From tim.peters at gmail.com  Fri Jul 29 17:57:06 2005
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 29 Jul 2005 11:57:06 -0400
Subject: [Python-Dev] math.fabs redundant?
In-Reply-To: <17130.17926.863069.507314@montanaro.dyndns.org>
References: <17130.17926.863069.507314@montanaro.dyndns.org>
Message-ID: <1f7befae050729085770d46069@mail.gmail.com>

[Skip]
> Why does math have an fabs function?  Both it and the abs builtin function
> wind up calling fabs() for floats.  abs() is faster to boot.

Nothing deep -- the math module supplies everything in C89's standard
libm (+ a few extensions), fabs() is a std C89 libm function.

There isn't a clear (to me) reason why one would be faster than the
other; sounds accidental; math.fabs() could certainly be made faster
(as currently implemented (via math_1), it endures a pile of
general-purpose "try to guess whether libm should have set errno"
boilerplate that's wasted (there are no domain or range errors
possible for fabs())).

From martin at v.loewis.de  Fri Jul 29 22:59:56 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 22:59:56 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA061A.9040609@egenix.com>
References: <42E93940.6080708@v.loewis.de> <42EA061A.9040609@egenix.com>
Message-ID: <42EA98CC.4060003@v.loewis.de>

M.-A. Lemburg wrote:
>>and on python.org instead of sf.net. To facilitate discussion,
>>I have drafted a PEP describing the rationale for doing so, and
>>the technical procedure to be performed.
> 
> 
> Not sure about the move to svn.python.org. This would
> bind additional developer resources for doing administration
> work.

True. OTOH, there already is a subversion on svn.python.org,
and administrative work is likely only about creating new
accounts. I guess the current SF project admins would help
out if help is needed.

> If SF is such a show-stopper

It is at the moment, atleast: there currently is not svn
support on sf.net.

> would it be reasonable to
> look for managed alternatives, such as eg. CollabNet (who
> funded Subversion development) ?

Perhaps. Somebody would need to research the precise migration
procedure. I once tried to move the Python CVS to Sunsite
(or its successors), and gave up after half a year of getting
nowhere; I'm personally not keen on repeating such an experience.

However, if somebody stepped forward to do the actual work
(perhaps based on the draft PEP), I would happily hand this
project over (it would be good if that volunteer would set
a deadline for negotiations with the new host).

Regards,
Martin

From martin at v.loewis.de  Fri Jul 29 23:02:52 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 23:02:52 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA2C7A.7000300@zope.com>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
	<42EA2C7A.7000300@zope.com>
Message-ID: <42EA997C.3070507@v.loewis.de>

Jim Fulton wrote:
>    I don't expect that this would be an issue for Python.

Right.

> 2. I initially tried to conver our entire repository, including all
>    branches.  This would have taken days.  I finally decided to just
>    convert our trunk, which took several hours.  The main time
>    sink was in the load step of the conversion process.
> 
>    I suspect that much of the time hit was due to the Berkely DB
>    back end.  I think I've heard that the file-system-based back end
>    is much faster in general.

Dunno. For the Python CVS (which translates into some 40,000 revisions),
on the machine which I was originally using (1GHz Pentium), conversion
took 7h. On my current workstation, it takes a little over an hour.

Regards,
Martin

From martin at v.loewis.de  Fri Jul 29 23:07:24 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 23:07:24 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA2EE5.3000502@zope.com>
References: <42E93940.6080708@v.loewis.de>	<1f7befae050728172161d4a9e8@mail.gmail.com>	<200507281956.03788.jeff@taupro.com>
	<1f7befae05072819142c36e610@mail.gmail.com>
	<42E9BA69.3070704@v.loewis.de> <42EA2EE5.3000502@zope.com>
Message-ID: <42EA9A8C.4030903@v.loewis.de>

Jim Fulton wrote:
> I did convert projects individually.  I told cvs2svn to just create dump
> files.  I then used svnload to load the dump files myself so that
> I could make each project a top-level directory with it's own
> trunk, branches and tags.
> 
> I'd be happy to share my scrips, although there's nothing all that
> complicated about them.

If that's how it worked, I'm sure I can cook my own. Just for
confirmation:  the svn revision numbers don't increase
chronologically across 'modules', right: i.e. the first
revision of the module that was converted second has a higher
revision than the last revision of the first module, even
though historically, the order should have been reverse.

Not that this worries me much, but I'd like to confirm there
is no other way.

Regards,
Martin

From jim at zope.com  Fri Jul 29 23:12:20 2005
From: jim at zope.com (Jim Fulton)
Date: Fri, 29 Jul 2005 17:12:20 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA997C.3070507@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
	<42EA2C7A.7000300@zope.com> <42EA997C.3070507@v.loewis.de>
Message-ID: <42EA9BB4.3040006@zope.com>

Martin v. L?wis wrote:
> Jim Fulton wrote:
> 
>>   I don't expect that this would be an issue for Python.
> 
> 
> Right.
> 
> 
>>2. I initially tried to conver our entire repository, including all
>>   branches.  This would have taken days.  I finally decided to just
>>   convert our trunk, which took several hours.  The main time
>>   sink was in the load step of the conversion process.
>>
>>   I suspect that much of the time hit was due to the Berkely DB
>>   back end.  I think I've heard that the file-system-based back end
>>   is much faster in general.
> 
> 
> Dunno. For the Python CVS (which translates into some 40,000 revisions),
> on the machine which I was originally using (1GHz Pentium), conversion
> took 7h. On my current workstation, it takes a little over an hour.

Was this with the file-system back end?  What is your current system?

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From jim at zope.com  Fri Jul 29 23:15:18 2005
From: jim at zope.com (Jim Fulton)
Date: Fri, 29 Jul 2005 17:15:18 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA9A8C.4030903@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>	<1f7befae050728172161d4a9e8@mail.gmail.com>	<200507281956.03788.jeff@taupro.com>
	<1f7befae05072819142c36e610@mail.gmail.com>
	<42E9BA69.3070704@v.loewis.de> <42EA2EE5.3000502@zope.com>
	<42EA9A8C.4030903@v.loewis.de>
Message-ID: <42EA9C66.4080307@zope.com>

Martin v. L?wis wrote:
> Jim Fulton wrote:
> 
>>I did convert projects individually.  I told cvs2svn to just create dump
>>files.  I then used svnload to load the dump files myself so that
>>I could make each project a top-level directory with it's own
>>trunk, branches and tags.
>>
>>I'd be happy to share my scrips, although there's nothing all that
>>complicated about them.
> 
> 
> If that's how it worked, I'm sure I can cook my own. Just for
> confirmation:  the svn revision numbers don't increase
> chronologically across 'modules', right: i.e. the first
> revision of the module that was converted second has a higher
> revision than the last revision of the first module, even
> though historically, the order should have been reverse.
> 
> Not that this worries me much, but I'd like to confirm there
> is no other way.

Right. The revision numbers reflect the order in which they are
added to the svn repo.  I'm pretty sure the revision meta data,
in particular the date, was retained.  This is an advantage
advantage of using the low-level dump/load mechanism.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

From martin at v.loewis.de  Fri Jul 29 23:21:37 2005
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 29 Jul 2005 23:21:37 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <dcchcp$ck8$1@sea.gmane.org>
References: <42E93940.6080708@v.loewis.de>
	<dcbs08$7b5$1@sea.gmane.org>	<200507290041.20634.fdrake@acm.org>
	<42E9B71F.9030905@v.loewis.de> <dcchcp$ck8$1@sea.gmane.org>
Message-ID: <42EA9DE1.3020700@v.loewis.de>

Fernando Perez wrote:
> For ipython, which recently went through cvs2svn, I found that moving over to a
> project/trunk structure was a few minutes worth of work.  Since svn has moving
> commands, it was just a matter of making the extra project/ directory and
> moving things one level down the hierarchy.  Even if cvs2svn doesn't quite
> create things the way you want them in the long run, svn is flexible enough
> that a few manual tweaks should be quite easy to perform.

Doesn't this give issues as *every* file the starts out renamed? e.g.
what if you want "revision 100 of project/trunk/foo", but, at revision
100, it really was trunk/project/foo?

Regards,
Martin

From martin at v.loewis.de  Fri Jul 29 23:19:04 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 23:19:04 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <2mk6ja0wr4.fsf@starship.python.net>
References: <42E93940.6080708@v.loewis.de> <2mk6ja0wr4.fsf@starship.python.net>
Message-ID: <42EA9D48.5000101@v.loewis.de>

Michael Hudson wrote:
> Would it work/how much risk would it be to create accounts with shell
> /bin/false?

It seems that the pydotorg admins are worried about such a prospect.

I believe this alone either won't work or won't be good enough (not
sure which one): If you have /bin/false as login shell, and still
manage to invoke /usr/bin/svnserve remotely, you can likely also
invoke /usr/bin/cat /etc/passwd remotely (or download and build
the root exploit via ssh).

So you would have restrict the set of valid programs to *only*
svnserve. This is possible, but difficult to manage (AFAIK).

> (still faintly bothered by ~/.subversion/auth/svn.simple/*...)

Indeed. I personally would prefer SSL client certificates. This
is still tricky (where do you get the passphrase for the private
key from (*)), but slightly better.

Regards,
Martin

(*) In case you wonder, I'm personally using the following techniques
here:
- on windows, remove the passphrase from the private key/.p12 file,
  and encrypt the file through NTFS encryption. Then you don't need
  to enter a passphrase, but still nobody can steal the private
  key from your disk (as long as you are not logged in; the same
  holds for ssh-agent)
- on Linux, my issue is that .subversion is on NFS, so any root
  user in our net can connect to the file. Therefore, I copy
  the .p12 file to /tmp/private_dir, and remove the passphrase
  there. No other machine can read the file (as /tmp is not
  exported), and the file goes away after machine shutdown
  latest (as tmp is cleaned on reboot).
- again on windows, I'm working on teaching subversion the
  Microsoft certificate store.




From martin at v.loewis.de  Fri Jul 29 23:32:23 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 29 Jul 2005 23:32:23 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA9BB4.3040006@zope.com>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com>
	<42EA2C7A.7000300@zope.com> <42EA997C.3070507@v.loewis.de>
	<42EA9BB4.3040006@zope.com>
Message-ID: <42EAA067.5030302@v.loewis.de>

Jim Fulton wrote:
>> Dunno. For the Python CVS (which translates into some 40,000 revisions),
>> on the machine which I was originally using (1GHz Pentium), conversion
>> took 7h. On my current workstation, it takes a little over an hour.
> 
> 
> Was this with the file-system back end?  What is your current system?

Yes, and it is a 3 GHz dual processor (although I don't think it uses
two processors) with 1GB RAM (I believe RAM size matters a lot for
this process; the older machine has 512MB).

Regards,
Martin

From barry at python.org  Fri Jul 29 23:54:15 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jul 2005 17:54:15 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E9B7D6.6010708@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>  <42E97519.6040101@ogre.com>
	<1122599962.9671.3.camel@geddy.wooz.org> <42E9B7D6.6010708@v.loewis.de>
Message-ID: <1122674055.10744.20.camel@geddy.wooz.org>

On Fri, 2005-07-29 at 01:00, "Martin v. L?wis" wrote:
> Barry Warsaw wrote:
> > We won't use plain text, but we may (or, we currently do) use basic auth
> > over ssl.  The security then is in the passwords, so we have to make
> > sure they're generated securely.
> 
> That (sort of) *is* plain text passwords. Somebody who took over
> svn.python.org can get the password. In public-key or digest
> authentication, this won't be possible.

Actually, the passwords are still hashed in the file, so they wouldn't
be able to extract the plain text password.  They definitely are
vulnerable to brute force attack, though probably not to a dictionary
attack.  In practice I've been using a password generated based on
os.urandom() -- we generate the password and get it to the Subversion
user via a "secure route" <heh>.   I'd be happy to share my password
generation script with anybody who wants to audit it.

Public/private keys would be better, and if anybody knows how to set up
a Subversion server to use these without having to create accounts for
everyone, I think we (the pythong.org admins) would love your help.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050729/cbed3ca0/attachment.pgp

From barry at python.org  Fri Jul 29 23:57:33 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jul 2005 17:57:33 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E9B432.9010406@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
	<ca471dc205072813205fe3d89f@mail.gmail.com>
	<42E9B432.9010406@v.loewis.de>
Message-ID: <1122674253.10747.24.camel@geddy.wooz.org>

On Fri, 2005-07-29 at 00:44, "Martin v. L?wis" wrote:

> - assignment of passwords. This I don't like about the current
>   pydotorg setup - there should be a way to chose your own password;
>   perhaps without involving an administrator.
>   I could imagine a web form for password change, and administrator
>   interaction in case of a lost password.

I disagree.  By reserving password generation to the pydotorg admins, we
can better insure the passwords are more robust against dictionary
attacks.  See my previous message.  I actually /don't/ want individuals
to be able to set their own passwords.  In practice, you only have to
know your password once, because svn caches the authentication (yes,
that opens up opportunities for compromise, but that's how svn works).

> - compromised passwords. The only tricky question then is: was the
>   repository altered? Fortunately, for Subversion, there should be
>   an easy way to tell: in fsfs, files never change (only new files
>   are added). So we could generate md5sums of all files in the
>   repository, and download these to an offsite place. If the md5sum
>   of an immutable file changes, we were compromised (there are,
>   of course, a few files that do change regularly).
>   Of course, we also need regular backups of the entire data
>   so we can restore them if they got compromised.

+1 to all that.
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050729/8aca20dc/attachment-0001.pgp

From fperez.net at gmail.com  Sat Jul 30 00:09:05 2005
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 29 Jul 2005 16:09:05 -0600
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
References: <42E93940.6080708@v.loewis.de>
	<dcbs08$7b5$1@sea.gmane.org>	<200507290041.20634.fdrake@acm.org>
	<42E9B71F.9030905@v.loewis.de> <dcchcp$ck8$1@sea.gmane.org>
	<42EA9DE1.3020700@v.loewis.de>
Message-ID: <dce9e2$44r$1@sea.gmane.org>

"Martin v. L?wis" wrote:

> Fernando Perez wrote:
>> For ipython, which recently went through cvs2svn, I found that moving over
>> to a
>> project/trunk structure was a few minutes worth of work.  Since svn has
>> moving commands, it was just a matter of making the extra project/ directory
>> and
>> moving things one level down the hierarchy.  Even if cvs2svn doesn't quite
>> create things the way you want them in the long run, svn is flexible enough
>> that a few manual tweaks should be quite easy to perform.
> 
> Doesn't this give issues as *every* file the starts out renamed? e.g.
> what if you want "revision 100 of project/trunk/foo", but, at revision
> 100, it really was trunk/project/foo?

To be honest, I don't really know the details, but it seems to work fine. A
quick look at ipython:

planck[IPython]> svn update
At revision 661.

planck[IPython]> svn diff -r 10 genutils.py | tail
-
-    Deprecated: this function has been superceded by timing() which has better
-    fucntionality."""
-
-    rng = range(reps)
-    start = time.clock()
-    for dummy in rng: func(*args,**kw)
-    return time.clock()-start
-
-#*************************** end of file <genutils.py> **********************

Revision 10 was most certainly back in the early CVS days, and the wholesale
renaming happened when I started using svn, which was around revision 600 or
so.  There may be other subtleties I'm missing, but so far I haven't
experienced any problems.

Cheers,

f


From leif at ogre.com  Sat Jul 30 00:12:15 2005
From: leif at ogre.com (Leif Hedstrom)
Date: Fri, 29 Jul 2005 15:12:15 -0700
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122674055.10744.20.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de> <42E97519.6040101@ogre.com>	
	<1122599962.9671.3.camel@geddy.wooz.org>
	<42E9B7D6.6010708@v.loewis.de>
	<1122674055.10744.20.camel@geddy.wooz.org>
Message-ID: <42EAA9BF.4050103@ogre.com>

Barry Warsaw wrote:

>
>Public/private keys would be better, and if anybody knows how to set up
>a Subversion server to use these without having to create accounts for
>everyone, I think we (the pythong.org admins) would love your help.
>  
>

I'll play around with it some this weekend, see what's possible, and was 
isn't. I'm thinking we ought to be able to use SSH's configuration to 
only allow one specific command, e.g. something like this in the 
authorized_keys:

   
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/bin/svnserve"

-- Leif



From barry at python.org  Sat Jul 30 00:12:16 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jul 2005 18:12:16 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA9D48.5000101@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
	<2mk6ja0wr4.fsf@starship.python.net>  <42EA9D48.5000101@v.loewis.de>
Message-ID: <1122675136.10751.39.camel@geddy.wooz.org>

On Fri, 2005-07-29 at 17:19, "Martin v. L?wis" wrote:

> I believe this alone either won't work or won't be good enough (not
> sure which one): If you have /bin/false as login shell, and still
> manage to invoke /usr/bin/svnserve remotely, you can likely also
> invoke /usr/bin/cat /etc/passwd remotely (or download and build
> the root exploit via ssh).
> 
> So you would have restrict the set of valid programs to *only*
> svnserve. This is possible, but difficult to manage (AFAIK).

I think that's basically right.

> - on Linux, my issue is that .subversion is on NFS, so any root
>   user in our net can connect to the file. Therefore, I copy
>   the .p12 file to /tmp/private_dir, and remove the passphrase
>   there. No other machine can read the file (as /tmp is not
>   exported), and the file goes away after machine shutdown
>   latest (as tmp is cleaned on reboot).

I don't think that's true on all Linuxes though (or even all *nixes).

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050729/e917d527/attachment.pgp

From barry at python.org  Sat Jul 30 00:19:59 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jul 2005 18:19:59 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42E9B22C.2030502@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
	<1122589831.23775.10.camel@geddy.wooz.org>
	<42E9B22C.2030502@v.loewis.de>
Message-ID: <1122675599.10747.45.camel@geddy.wooz.org>

On Fri, 2005-07-29 at 00:35, "Martin v. L?wis" wrote:

> It's also a convenience issue, and has social aspects. For example,
> firstname.lastname does not work quite well for me, either
> (martin.v.loewis or martin.von.loewis would work better; likewise
> guido.van.rossum?), other users prefer not to use their "true"
> real name (e.g. tim_one vs. tim.peters).

Yep, we would use guido.van.rossum.  I think it would be fine for you to
use martin.v.loewis or martin.von.loewis, just as MAL could use
m.a.lemburg or marc.andre.lemberg.  Our general concern was people
hiding behind obscure nicknames like 'pumpichank' and no one really
knowing who's behind that <wink>.

> Another issue is password assignment - currently, users cannot choose
> their passwords on svn.python.org, right?

Correct, which I think is a feature. :)

> Then you could give different access to peps and to sandbox.
> Perhaps there isn't even a need for tags/branches on PEPs?

Probably so.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050729/1252d737/attachment.pgp

From martin at v.loewis.de  Sat Jul 30 00:22:18 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 30 Jul 2005 00:22:18 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122674253.10747.24.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de>	
	<ca471dc205072813205fe3d89f@mail.gmail.com>
	<42E9B432.9010406@v.loewis.de>
	<1122674253.10747.24.camel@geddy.wooz.org>
Message-ID: <42EAAC1A.3090605@v.loewis.de>

Barry Warsaw wrote:
> I disagree.  By reserving password generation to the pydotorg admins, we
> can better insure the passwords are more robust against dictionary
> attacks.  See my previous message.  I actually /don't/ want individuals
> to be able to set their own passwords.  In practice, you only have to
> know your password once, because svn caches the authentication (yes,
> that opens up opportunities for compromise, but that's how svn works).

See Michael's (I think) message: that is a much greater risk than the
one of a brute-force attack. In our environment, a determined student
could easily read out my home directory, and get at my pydotorg password
(if I would allow svn to cache it). They would have to break all kinds
of rules in doing so; yet, it would be technically possible - so
I just can't turn on this svn setting, and have to type the password
every time. This is surely inconvenient, as I cannot even remember
the password.

Regards,
Martin

From barry at python.org  Sat Jul 30 00:23:13 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jul 2005 18:23:13 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EAA067.5030302@v.loewis.de>
References: <42E93940.6080708@v.loewis.de>
	<1f7befae050728172161d4a9e8@mail.gmail.com> <42EA2C7A.7000300@zope.com>
	<42EA997C.3070507@v.loewis.de> <42EA9BB4.3040006@zope.com>
	<42EAA067.5030302@v.loewis.de>
Message-ID: <1122675793.10752.49.camel@geddy.wooz.org>

On Fri, 2005-07-29 at 17:32, "Martin v. L?wis" wrote:

> > Was this with the file-system back end?  What is your current system?
> 
> Yes, and it is a 3 GHz dual processor (although I don't think it uses
> two processors) with 1GB RAM (I believe RAM size matters a lot for
> this process; the older machine has 512MB).

That matches my experience w/ the fsfs backend.  If we do the conversion
on one of the new python.org boxes, I expect it to go pretty quickly.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050729/ea5613a7/attachment.pgp

From martin at v.loewis.de  Sat Jul 30 00:15:50 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 30 Jul 2005 00:15:50 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122674055.10744.20.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de> <42E97519.6040101@ogre.com>	
	<1122599962.9671.3.camel@geddy.wooz.org>
	<42E9B7D6.6010708@v.loewis.de>
	<1122674055.10744.20.camel@geddy.wooz.org>
Message-ID: <42EAAA96.10904@v.loewis.de>

Barry Warsaw wrote:
>>That (sort of) *is* plain text passwords. Somebody who took over
>>svn.python.org can get the password. In public-key or digest
>>authentication, this won't be possible.
> 
> 
> Actually, the passwords are still hashed in the file, so they wouldn't
> be able to extract the plain text password.

Nah. Somebody who takes over svn.python.org can replace Apache, and that
will receive plain text passwords over the wire (in case you wonder:
modules/aaa/mod_auth.c:authenticate_real_user - you can even write an
Apache module that gets hold of the sent password).

An intruder would have to wait some time before the password come in,
instead of being able to read them all from a file at once - that's
true.

> Public/private keys would be better, and if anybody knows how to set up
> a Subversion server to use these without having to create accounts for
> everyone, I think we (the pythong.org admins) would love your help.

Ok. Since this falls in my research interest, I definitely want to give
it a try. I think I would set up PyCA to let users generate their
private keys in the browser.

Regards,
Martin

From barry at python.org  Sat Jul 30 00:28:49 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jul 2005 18:28:49 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <59d991c4050728215038182832@mail.gmail.com>
References: <42E93940.6080708@v.loewis.de> <dcbs08$7b5$1@sea.gmane.org>
	<200507290041.20634.fdrake@acm.org>
	<59d991c4050728215038182832@mail.gmail.com>
Message-ID: <1122676129.10751.55.camel@geddy.wooz.org>

On Fri, 2005-07-29 at 00:50, Christopher Petrilli wrote:

> Another thing to look at would be Trac, which we are in the process of
> moving to from the horrendous nightmare of Bugzilla.  It's integration
> with SVN as well as Wiki is quite amazing.

Now's the time I pipe in to remind everyone that Atlassian has offered
free (as in beer) versions of Jira and Confluence for the Python project
(actually any open source project).  If you haven't used these, they're
definitely worth a look.  Jira is the issue tracker, Confluence the
wiki.  They're extremely professional, usable, well-integrated, and you
can integrate them with Subversion.  We've used them at work for maybe a
year now and I've been very happy with them.  Jira is definitely one of
the better issue trackers, free or not free, that I've used.

www.atlassian.com

They're not Python and they're not open source, so perhaps it's
legitimate to dismiss them because of that.  But they are also
definitely cool.  At the Atlassian folks are very cool too, and fans of
FOSS.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050729/e2366f2e/attachment.pgp

From pje at telecommunity.com  Sat Jul 30 00:29:10 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 29 Jul 2005 18:29:10 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122674055.10744.20.camel@geddy.wooz.org>
References: <42E9B7D6.6010708@v.loewis.de> <42E93940.6080708@v.loewis.de>
	<42E97519.6040101@ogre.com>
	<1122599962.9671.3.camel@geddy.wooz.org>
	<42E9B7D6.6010708@v.loewis.de>
Message-ID: <5.1.1.6.0.20050729182002.028765a0@mail.telecommunity.com>

At 05:54 PM 7/29/2005 -0400, Barry Warsaw wrote:
>Public/private keys would be better, and if anybody knows how to set up
>a Subversion server to use these without having to create accounts for
>everyone, I think we (the pythong.org admins) would love your help.

 From the svnserve man page:

  -t, --tunnel
     Causes  svnserve  to  run  in tunnel mode, which is just like the
     inetd mode of operation (serve one connection over  stdin/stdout)
     except  that the connection is considered to be pre-authenticated
     with the username of the current uid.  This flag is  selected  by
     the client when running over a tunnel agent.

  --tunnel-user=username
     When  combined  with  --tunnel,  overrides  the pre-authenticated
     username with the supplied username.  This is useful in  combina-
     tion  with  the  ssh authorized_key file's "command" directive to
     allow a single system account to be used by multiple  committers,
     each having a distinct ssh identity.

So, it looks like you'd just need to set up public keys for each user, and 
list them in authorized_keys.  Presumably doing something like this:

command="/usr/bin/svnserve --root=/svnroot -t 
--tunnel-user=username",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding 
ssh-rsa [key info here]

would therefore do the trick.  I've used a similar arrangement for my own 
CVS repository, but haven't tried it for SVN yet.



From barry at python.org  Sat Jul 30 00:31:42 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jul 2005 18:31:42 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA9DE1.3020700@v.loewis.de>
References: <42E93940.6080708@v.loewis.de> <dcbs08$7b5$1@sea.gmane.org>
	<200507290041.20634.fdrake@acm.org> <42E9B71F.9030905@v.loewis.de>
	<dcchcp$ck8$1@sea.gmane.org>  <42EA9DE1.3020700@v.loewis.de>
Message-ID: <1122676301.10744.57.camel@geddy.wooz.org>

On Fri, 2005-07-29 at 17:21, "Martin v. L?wis" wrote:

> Doesn't this give issues as *every* file the starts out renamed? e.g.
> what if you want "revision 100 of project/trunk/foo", but, at revision
> 100, it really was trunk/project/foo?

I think it only matters if you use urls.  I working directories, I think
everything gets tracked correctly.  I could be wrong about that though.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050729/e83462b5/attachment.pgp

From barry at python.org  Sat Jul 30 00:35:47 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jul 2005 18:35:47 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EA98CC.4060003@v.loewis.de>
References: <42E93940.6080708@v.loewis.de> <42EA061A.9040609@egenix.com>
	<42EA98CC.4060003@v.loewis.de>
Message-ID: <1122676547.10752.61.camel@geddy.wooz.org>

On Fri, 2005-07-29 at 16:59, "Martin v. L?wis" wrote:

> Perhaps. Somebody would need to research the precise migration
> procedure. I once tried to move the Python CVS to Sunsite
> (or its successors), and gave up after half a year of getting
> nowhere; I'm personally not keen on repeating such an experience.

I'm with you.  SF is a devil we know.  If we don't stick with them (and
it looks like that's not an option if we want to switch to svn soon),
then I say we move it to svn.python.org, where we already have a server
set up and running.  If we need more volunteers, well the community has
always stepped up before and I'm sure it will when we come asking again.

Actually, it's a good idea to /always/ be soliciting for help.  People
get burned out and busy and I'd love to have a bullpen of volunteers
that gets constantly refreshed.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050729/11aed324/attachment.pgp

From barry at python.org  Sat Jul 30 00:39:58 2005
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jul 2005 18:39:58 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EAA9BF.4050103@ogre.com>
References: <42E93940.6080708@v.loewis.de>  <42E97519.6040101@ogre.com>
	<1122599962.9671.3.camel@geddy.wooz.org> <42E9B7D6.6010708@v.loewis.de>
	<1122674055.10744.20.camel@geddy.wooz.org> <42EAA9BF.4050103@ogre.com>
Message-ID: <1122676798.10747.65.camel@geddy.wooz.org>

On Fri, 2005-07-29 at 18:12, Leif Hedstrom wrote:
> Barry Warsaw wrote:
> 

> >Public/private keys would be better, and if anybody knows how to set up
> >a Subversion server to use these without having to create accounts for
> >everyone, I think we (the pythong.org admins) would love your help.

> I'll play around with it some this weekend, see what's possible, and was 
> isn't. I'm thinking we ought to be able to use SSH's configuration to 
> only allow one specific command, e.g. something like this in the 
> authorized_keys:

> no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/bin/svnserve"

But that would still require us to create accounts for every committer,
right?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20050729/0251e7b9/attachment.pgp

From pje at telecommunity.com  Sat Jul 30 01:00:27 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 29 Jul 2005 19:00:27 -0400
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122676798.10747.65.camel@geddy.wooz.org>
References: <42EAA9BF.4050103@ogre.com> <42E93940.6080708@v.loewis.de>
	<42E97519.6040101@ogre.com>
	<1122599962.9671.3.camel@geddy.wooz.org>
	<42E9B7D6.6010708@v.loewis.de>
	<1122674055.10744.20.camel@geddy.wooz.org>
	<42EAA9BF.4050103@ogre.com>
Message-ID: <5.1.1.6.0.20050729185927.02709c98@mail.telecommunity.com>

At 06:39 PM 7/29/2005 -0400, Barry Warsaw wrote:
>But that would still require us to create accounts for every committer,
>right?

No.  Just one account.  You can have more than one key listed in 
authorized_keys, using svnserve --tunnel-user and sshd will select the 
right command based on the public key the client authenticates with.


From ncoghlan at gmail.com  Sat Jul 30 01:15:32 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 30 Jul 2005 09:15:32 +1000
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122676129.10751.55.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de>
	<dcbs08$7b5$1@sea.gmane.org>	<200507290041.20634.fdrake@acm.org>	<59d991c4050728215038182832@mail.gmail.com>
	<1122676129.10751.55.camel@geddy.wooz.org>
Message-ID: <42EAB894.5070900@gmail.com>

Barry Warsaw wrote:
> Now's the time I pipe in to remind everyone that Atlassian has offered
> free (as in beer) versions of Jira and Confluence for the Python project
> (actually any open source project).  If you haven't used these, they're
> definitely worth a look.  Jira is the issue tracker, Confluence the
> wiki.  They're extremely professional, usable, well-integrated, and you
> can integrate them with Subversion.  We've used them at work for maybe a
> year now and I've been very happy with them.  Jira is definitely one of
> the better issue trackers, free or not free, that I've used.
> 
> www.atlassian.com

I've also used Confluence at work, and been very impressed. A very nice 
feature which I haven't seen anywhere else is that the Wiki pages allow 
comments as well as direct editing - it allows discussion *about* the page to 
occur in a normal answer/response fashion, possibly leading to eventual update 
of the page text itself.

> They're not Python and they're not open source, so perhaps it's
> legitimate to dismiss them because of that.  But they are also
> definitely cool.  At the Atlassian folks are very cool too, and fans of
> FOSS.

I'd hope we wouldn't dismiss them out of hand - one of the things that appeals 
to me about Python is the philosophy that open-source and protected-source 
groups can both benefit from working together.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From bcannon at gmail.com  Sat Jul 30 02:34:07 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Fri, 29 Jul 2005 17:34:07 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Message-ID: <bbaeab100507291734337930a2@mail.gmail.com>

Well, it has been discussed at multiple times in the past and I have
promised to write this PEP several times, so I finally found enough
time to write a PEP on reorganizing exceptions for Python 3.0 .

Key points in this PEP is the reworking the hierarchy, requiring
anything raised to inherit from a certain superclass, and to change
bare 'except' clauses to catch a specific superclass.  The first and
last points I expect some contention, but the middle point I expect
people are okay with (Guido liked the idea when Paul Prescod brought
it up and the only person who didn't like it, Holger, ended up being
okay with it when the superclass had a reasonable name).

One thing people might not notice is that I have some minor ideas
listed in the tree in parentheses.  If people have an opinion on the
ideas please speak up.

Otherwise the other major points of contention are covered in the Open
Issues section or will be brought up in the usual trashing of PEPs
that cover contraversial changes.

And please realize this is for Python 3.0!  None of this is being
proposed for any version before then (they could be, but that is
another PEP entirely).  Hopefully this PEP along with Ping's PEP 344
will cover the major ideas for exceptions for Python 3.0 .

-Brett

--------------------------------------------------------------

PEP: XXX
Title: Exception Reorganization for Python 3.0
Version: $Revision: 1.5 $
Last-Modified: $Date: 2005/06/07 13:17:37 $
Author: Brett Cannon <brett at python.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Jul-2005
Post-History: XX-XXX-XXX


Abstract
========

Python, as of version 2.4, has 38 exceptions (including warnings) in
the built-in namespace in a rather shallow hierarchy.
This list of classes has grown over the years without a chance to
learn from mistakes and cleaning up the hierarchy.
This PEP proposes doing a reorganization for Python 3000 when
backwards-compatibility is not an issue.
It also proposes changing bare ``except`` clauses to catch only
exceptions inheriting from a specific superclass.
Lastly, this PEP proposes, in Python 3000, that all objects to be
passed to a ``raise`` statement must inherit from a specific
superclass.


Rationale
=========

Exceptions are a critical part of Python.
While exceptions are traditionally used to signal errors in a program,
they have also grown to be used for flow control for things such as
iterators.
There importance is great.

But the organization of the exception hierarchy has not been maintained.
Mostly for backwards-compatibility reasons, the hierarchy has stayed
very flat and old exceptions who usefulness have not been proven have
been left in.
Making exceptions more hierarchical would help facilitate exception
handling by making catching exceptions much more logical with use of
superclasses.
This should also help lead to less errors from being too broad in what
exceptions are caught in an ``except`` clause.

A required superclass for all exceptions is also being proposed
[Summary2004-08-01]_.
By requiring any object that is used in a ``raise`` statement to
inherit from a specific superclass, certain attributes (such as those
laid out in PEP 344 [PEP344]_) can be guaranteed to exist.
This also will lead to the planned removal of string exceptions.

Lastly, bare ``except`` clauses can be made less error-prone
[Summary2004-09-01]_.
Often people use a bare ``except`` when what they really wanted were
non-critical exceptions to be caught while more system-specific ones,
such as MemoryError, to pass through and to halt the interpreter.
With a hierarchy reorganization, bare ``except`` clauses can be
changed to only catch exceptions that subclass a non-critical
exception superclass, allowing more critical exceptions to propagate
to the top of the execution stack as was most likely intended.


Philosophy of Reorganization
============================

There are several goals in this reorganization that defined the
philosophy used to guide the work.
One goal was to prune out unneeded exceptions.
Extraneous exceptions should not be left in since it just serves to
clutter the built-in namespace.
Unneeded exceptions also dilute the importance of other exceptions by
splitting uses between several exceptions when all uses should have
been under a single exception.

Another goal was to introduce any exceptions that were deemed needed
to fill any holes in the hierarchy.
Most new exceptions were done to flesh out the inheritance hierarchy
to make it easier to catch a category of exceptions with a simpler
``except`` clause.

Changing inheritance to make it more reasonable was a goal.
As stated above, having proper inheritance allows for more accurate
``except`` statements when catching exceptions based on the
inheritance tree.

Lastly, any renaming to make an exception's use more obvious from its
name was done.
Having to look up what an exception is meant to be used for because
the name does not proper reflect its usage is annoying and slows down
debugging.
Having a proper name also makes debugging easier on new programmers.


New Hierarchy
=============

Raisable (new; rename BaseException?)
+-- CriticalException (new)
    +-- KeyboardInterrupt
    +-- MemoryError
    +-- SystemExit
    +-- SystemError (subclass SystemExit?)
    +-- AssertionError
    +-- SyntaxError
        +-- IndentationError
            +-- TabError
+-- Exception (replaces StandardError)
    +-- ArithmeticError
        +-- FloatingPointError
        +-- DivideByZeroError
        +-- OverflowError
    +-- ControlFlowException (new)
        +-- StopIteration
        +-- GeneratorExit (introduced by PEP 342 [PEP342]_; subclass
StopIteration?)
    +-- UnicodeError
        +-- UnicodeDecodeError
        +-- UnicodeEncodeError
        +-- UnicodeTranslateError (subclass UnicodeEncodeError and
UnicodeDecodeError?)
    +-- LookupError (better name?)
        +-- IndexError
        +-- KeyError
    +-- TypeError
        +-- AttributeError (subclassing new)
    +-- OSError (does not inherit from EnvironmentError)
        +-- WindowsError
        +-- MacError (new)
        +-- UnixError (new)
    +-- IOError (does not inherit from EnvironmentError)
        +-- EOFError (subclassing new)
    +-- ImportError
    +-- NotImplementedError
    +-- NamespaceException (new)
        +-- UnboundGlobalError (new name for NameError)
        +-- UnboundLocalError (no longer subclasses UnboundGlobalError
which replaces NameError)
    +-- WeakReferenceError (rename for ReferenceError)
    +-- ValueError
+-- Warning
    +-- UserWarning
    +-- PendingDeprecationWarning
        +-- DeprecationWarning (subclassing new)
    +-- SyntaxWarning
    +-- SemanticsWarning (new name for RuntimeWarning)
    +-- FutureWarning


Differences Compared to Python 2.4
==================================

Changes to exceptions from Python 2.4 can take shape in three forms:
removal, renaming, or change in their superclass.
There are also new exceptions introduced in the proposed hierarchy.


New Exceptions
--------------

Raisable
''''''''

The base exception **all** exceptions inherit from.
The name "Raisable" has been chosen to reflect that it is not meant to
be treated as an exception directly, but as the common object that all
things to base passed to ``raise`` must inherit from.


CriticalException
'''''''''''''''''

The superclass for exceptions for which a severe error has occurred
that one would not want to catch accidentally.
The name is meant to reflect the point that these exceptions are
usually raised only when the interpreter should most likely be
terminated.


MacError
''''''''

Introduced for symmertry with WindowsError.


UnixError
'''''''''

Introduced for symmetry with WindowsError.


NamespaceException
''''''''''''''''''

To provide a common superclass for exceptions dealing with namespace
issues, this exception is introduced.
Both UnboundLocalError and UnboundGlobalError (the new name for
NameError) inherit from this class.


Removed Exceptions
------------------

EnvironmentError
''''''''''''''''

Originally meant as an exception for when an event outside of the
interpreter needed to raise an exception, its use has been deemed
unneeded.
While both IOError and OSError inherited this class, the distinction
between OS and I/O is significant enough to not warrant having a
common subclass that one might base an ``except`` clause on.


StandardError
'''''''''''''

Originally meant to act as a superclass for exceptions not considered
critical, its subclassing was rampant and partially negated its
usefulness.
The need for StandardError is negated thanks to the
CriticalException/Exception dichotomy where Exception takes its place.


RuntimeError
''''''''''''
Meant to be used when an existing exception does not fit, its
usefulness is consider meager in Python 2.4 [exceptionsmodule]_.
Also, with the CriticalException/Exception dichotomy, Exception or
CriticalException can be raised directly for the same use.


Renamed Exceptions
------------------

ReferenceError
''''''''''''''

Renamed WeakReferenceError.

ReferenceError was added to the built-in exception hierarchy in Python
2.2 [exceptionsmodule]_.
Taken directly from the ``weakref`` module, its name comes directly
from its original name when it resided in the module.
Unfortunately its name does not suggest its connection to weak
references and thus deserves a renaming.


NameError
'''''''''

Renamed UnboundGlobalError.

While NameError suggests its use, the name does not properly restrict its scope.
With UnboundLocalError already in existence, it seems reasonable to
change NameError to UnboundGlobalError to brings its name more in
line.


RuntimeWarning
''''''''''''''

Renamed SemanticsWarning.

RuntimeWarning is to represent semantic changes coming in the future.
But while saying that affects "runtime" is true, flat-out stating it
is a semantic change is much clearer, eliminating any possible
association of "runtime" with the virtual machine specifically.


Changed Inheritance
-------------------

StopIteration and GeneratorExit
'''''''''''''''''''''''''''''''

Inherit from ControlFlowException.

Collecting all control flow-related exceptions under a common
superclass continues with the theme of maintaining a hierarchy.


AttributeError
''''''''''''''

Inherits TypeError.

Since most attribute access errors can be attributed to an object not
being the type that one expects, it makes sense for AttributeError to
be considered a type error.


IOError
'''''''

No longer subclasses EnvironmentError.

While IOError does fall under the umbrella of EnvironmentError, the
need for EnvironmentError has been deemed wanting, and thus has been
removed.
Thus IOError now subclasses Exception directly.


EOFError
''''''''

Subclasses IOError.

Since an EOF comes from I/O it only makes sense that it be considered
an I/O error.


UnboundGlobalError and UnboundLocalError
''''''''''''''''''''''''''''''''''''''''

Both subclass NamespaceException.

Originally UnboundLocalError subclassed NameError (original name of
UnboundGlobalError), but with both exceptions specifying a certain
namespace, that subclassing has been deemed inappropriate.
Instead, a common class between the two of them has been introduced.


DeprecationWarning
'''''''''''''''''''

Subclasses PendingDeprecationWarning.

Since a DeprecationWarning is a PendingDeprecationWarning that is
happening sooner, if you care about PendingDeprecationWarnings you are
defintely going to care about DeprecationWarnings.


Required Base Class for ``raise``
=================================

By requiring all objects passed to a ``raise`` statement, one is
guaranteed that all exceptions will have certain attributes.
If PEP 342 [PEP344]_ is accepted, the attributes outlined there will
be guaranteed to be on all exceptions raised.
This should help facilitate debugging by making the querying of
information from exceptions much easier.

Technically speaking, this can be easily implemented by modifying
``RAISE_VARARGS`` to do an inheritance check and raise TypeError if it
does not inherit from Raisable.


Bare ``except`` Clauses
=======================

Bare ``except`` clauses typically are not meant to catch all exceptions.
Often times catching KeyboardInterrupt is not intended.
Unfortunately the exception hierarchy in Python 2.4 does not support a
simple way to control what exceptions are caught except to be very
explicit with a list of exceptions.
The reorganization changes this by adding more of a hierarchy.

If bare ``except`` statements only catch classes that inherit from
Exception, its use will be more in line with what people expect.
An implementation can be handled at the bytecode level by modifying
the compiler to emit bytecode to do a check for Exception when a bare
``except`` is used.


Open Issues
===========

Change the Name of Raisable?
----------------------------

It has been argued that Raisable is a bad name to use since it is not
an actual word [python-dev1]_.
At issue is choosing a name that clearly explains the class' usage.
"BaseException" might be acceptable although the name does not quite
make it as explicit as Raisable that the class is not meant to be
raised directly.


Should Bare ``except`` Clauses be Removed?
------------------------------------------

It has been argued that bare ``except`` clauses should be removed
entirely [python-dev2]_.
The train of thought is that it will force people to specify what they
want to catch and not be too broad.
One issue with this, though, is whether people will make the proper
choices of what to catch or go too broadly.
Would a new Python programmer make the right decision and not catch
CriticalExceptions or would they go overboard and catch Raisable?
It would seem the issue boils down to whether we think people will
make proper decisions or make a reasonable solution available for the
simplest case assuming they might make a bad one.


Change the name of Exception?
-----------------------------

Some have suggested names other than "Exception" for the superclass to
inherit from for bare ``except`` clauses to match against.
The issue with going with a name that is not simplistic is that it
raises the chance of people subclassing the wrong exception for what
they want.
By using the most generic name for the common case it raises the
chances that people will use this class for subclassing their own
exceptions rather than Raisable or CriticalException.


Acknowledgements
================

XXX


References
==========

.. [PEP342] PEP 342 (Coroutines via Enhanced Generators)
            (http://www.python.org/peps/pep-0342.html)

.. [PEP344] PEP 344 (Exception Chaining and Embedded Tracebacks)
            (http://www.python.org/peps/pep-0344.html)

.. [exceptionsmodules] 'exceptions' module
            (http://docs.python.org/lib/module-exceptions.html)

.. [Summary2004-08-01] python-dev Summary (An exception is an
exception, unless it doesn't inherit from Exception)
            (http://www.python.org/dev/summary/2004-08-01_2004-08-15.html#an-exception-is-an-exception-unless-it-doesn-t-inherit-from-exception)

.. [Summary2004-09-01] python-dev Summary (Cleaning the Exception House)
            (http://www.python.org/dev/summary/2004-09-01_2004-09-15.html#cleaning-the-exception-house)

.. [python-dev1] python-dev email (Exception hierarchy)
            (http://mail.python.org/pipermail/python-dev/2004-August/047908.html)

.. [python-dev2] python-dev email (Dangerous exceptions)
            (http://mail.python.org/pipermail/python-dev/2004-September/048681.html)


Copyright
=========

This document has been placed in the public domain.

From gvanrossum at gmail.com  Sat Jul 30 04:41:37 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Fri, 29 Jul 2005 19:41:37 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab100507291734337930a2@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
Message-ID: <ca471dc205072919417fc15d68@mail.gmail.com>

On 7/29/05, Brett Cannon <bcannon at gmail.com> wrote:
> Well, it has been discussed at multiple times in the past and I have
> promised to write this PEP several times, so I finally found enough
> time to write a PEP on reorganizing exceptions for Python 3.0 .

Thanks for getting this ball rolling!

(I wonder what happened to Ping's PEP 344 -- he just dropped out, it
seems.)

Below is some feedback.

> Often people use a bare ``except`` when what they really wanted were
> non-critical exceptions to be caught while more system-specific ones,
> such as MemoryError, to pass through and to halt the interpreter.
> With a hierarchy reorganization, bare ``except`` clauses can be
> changed to only catch exceptions that subclass a non-critical
> exception superclass, allowing more critical exceptions to propagate
> to the top of the execution stack as was most likely intended.

I appreciate the attempt to make bare except: less dangerous by not
catching certain exceptions, but I worry that these changes might
actually make bare except: *more* likely to be used, which is contrary
to the intention.  Maybe we should just get rid of it, and encourage
people to write

    except Exception:

or

    except Raisable:

depending on what they want.

> MacError
> UnixError

Do we really need these?  Let's not add things that won't be used.

> NamespaceException
> 
> To provide a common superclass for exceptions dealing with namespace
> issues, this exception is introduced.
> Both UnboundLocalError and UnboundGlobalError (the new name for
> NameError) inherit from this class.

OTOH there's something to say to unify NameError and AttributeError,
isn't there?
> EnvironmentError
> 
> Originally meant as an exception for when an event outside of the
> interpreter needed to raise an exception, its use has been deemed
> unneeded.
> While both IOError and OSError inherited this class, the distinction
> between OS and I/O is significant enough to not warrant having a
> common subclass that one might base an ``except`` clause on.

-1000.  Depending on whether you use open() or os.open() you'll get
one or the other for pretty much the same thing.

Also, I think that socket.error and select.error should inherit from
EnvironmentError (or maybe even from OSError).

> RuntimeError

> Meant to be used when an existing exception does not fit, its
> usefulness is consider meager in Python 2.4 [exceptionsmodule]_.
> Also, with the CriticalException/Exception dichotomy, Exception or
> CriticalException can be raised directly for the same use.

-0.5.  I use it all the time as the "application" exception in apps
(scripts) that are too small to define their own exception hierarchy.

> StopIteration and GeneratorExit
> 
> Inherit from ControlFlowException.
> 
> Collecting all control flow-related exceptions under a common
> superclass continues with the theme of maintaining a hierarchy.

Yes, but how useful it this?  I don't expect to ever come across a
situation where I'd want to catch both, so this is more for
organization of the docs than for anything else.

IMO a good principle for determining the ideal exception hierarchy is
whether there's a use case for catching the common base class.

> IOError
> 
> No longer subclasses EnvironmentError.

-1000, see above.

> Change the Name of Raisable?
> 
> It has been argued that Raisable is a bad name to use since it is not
> an actual word [python-dev1]_.

Then we'll make it a word.  Is Java's equivalent, Throwable, any more
a word?  In this case I like the parallel with Java.

> Should Bare ``except`` Clauses be Removed?

Yes, see above.

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

From fumanchu at amor.org  Sat Jul 30 05:07:45 2005
From: fumanchu at amor.org (Robert Brewer)
Date: Fri, 29 Jul 2005 20:07:45 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Message-ID: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>

Brett Cannon wrote:
> New Hierarchy
> =============
> 
> Raisable (new; rename BaseException?)
> +-- CriticalException (new)
>     +-- KeyboardInterrupt
>     +-- MemoryError
>     +-- SystemExit
>     +-- SystemError (subclass SystemExit?)

I'd recommend not subclassing SystemExit--there are too many programs
out there which expect the argument (e.g. sys.exit(3)) to mean something
specific, but that expectation doesn't apply at all to SystemError.

> +-- Exception (replaces StandardError)
>...
>     +-- ControlFlowException (new)

I'd definitely appreciate ControlFlowException--there are a number of
exceptions in CherryPy which should subclass from that. Um, CherryPy
3.0, that is. ;)

>     +-- LookupError (better name?)

SubscriptError, perhaps? But LookupError could become the "I didn't find
obj X in the container you specified" superclass, in which case
LookupError is perfect.

>     +-- TypeError
>         +-- AttributeError (subclassing new)

"Since most attribute access errors can be attributed to an object not
being the type that one expects, it makes sense for AttributeError to
be considered a type error."

Very hmmm. I would have thought it would be a LookupError instead, only
because I favor the duck-typing parts of Python. Making AttributeError
subclass from TypeError leans toward stronger typing models a bit too
much, IMO.

>     +-- WeakReferenceError (rename for ReferenceError)

This also has a LookupError feel to it.

> It has been argued that Raisable is a bad name to use since it is not
> an actual word [python-dev1]_.

Perhaps, but compare http://www.onelook.com/?w=raisable to
http://www.onelook.com/?w=raiseable. The only sources "raiseable" has
going for it are Dictionary.com (which aggregates lots of questionable
sources), Rhymezone, and LookWAYup. I think "raisable" is the clear
winner.


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org

From gvanrossum at gmail.com  Sat Jul 30 05:22:48 2005
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Fri, 29 Jul 2005 20:22:48 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
References: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
Message-ID: <ca471dc2050729202220bb1d63@mail.gmail.com>

On 7/29/05, Robert Brewer <fumanchu at amor.org> wrote:
> >     +-- SystemExit
> >     +-- SystemError (subclass SystemExit?)
> 
> I'd recommend not subclassing SystemExit--there are too many programs
> out there which expect the argument (e.g. sys.exit(3)) to mean something
> specific, but that expectation doesn't apply at all to SystemError.

Agreed. SystemExit is used by sys.exit(); SystemError is something
completely different, used by the interpreter when it finds an
internal invariant is broken. It is one step short of a fatal error --
the latter is used when we have evidence of random memory scribbling,
the former when the interpreter is still intact.

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

From fdrake at acm.org  Sat Jul 30 05:38:10 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 29 Jul 2005 23:38:10 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
References: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
Message-ID: <200507292338.11157.fdrake@acm.org>

On Friday 29 July 2005 23:07, Robert Brewer wrote:
 > >     +-- WeakReferenceError (rename for ReferenceError)
 >
 > This also has a LookupError feel to it.

I disagree.

LookupError is used when looking for an object within some containing object 
according to some sort of key (dict key, index, etc.).  It's usually a 
reasonable expectation that there might not be an object associated with that 
key.  You also know that a different object may be returned at different 
times; you care about the association of the object with the key.

For weak references, you're not using a key in a container, you're resolving a 
specific reference that you know exists; what you don't know is whether the 
object still exists.  There's no indirection through a key as there is for 
LookupError.

I'm +0 on the WeakReferenceError name, but -1 on making it a subclass of 
LookupError.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From bcannon at gmail.com  Sat Jul 30 09:52:04 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 00:52:04 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <ca471dc205072919417fc15d68@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<ca471dc205072919417fc15d68@mail.gmail.com>
Message-ID: <bbaeab100507300052748840dd@mail.gmail.com>

On 7/29/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> On 7/29/05, Brett Cannon <bcannon at gmail.com> wrote:
> > Well, it has been discussed at multiple times in the past and I have
> > promised to write this PEP several times, so I finally found enough
> > time to write a PEP on reorganizing exceptions for Python 3.0 .
> 
> Thanks for getting this ball rolling!
> 

No problem.  Had this bouncing around in my head for a while.  I just
needed time to finally type it out.

> (I wonder what happened to Ping's PEP 344 -- he just dropped out, it
> seems.)
> 

Don't know.  If he doesn't come back I will pick up the attribute part
and roll it into this PEP or a separate PEP.

> Below is some feedback.
> 
> > Often people use a bare ``except`` when what they really wanted were
> > non-critical exceptions to be caught while more system-specific ones,
> > such as MemoryError, to pass through and to halt the interpreter.
> > With a hierarchy reorganization, bare ``except`` clauses can be
> > changed to only catch exceptions that subclass a non-critical
> > exception superclass, allowing more critical exceptions to propagate
> > to the top of the execution stack as was most likely intended.
> 
> I appreciate the attempt to make bare except: less dangerous by not
> catching certain exceptions, but I worry that these changes might
> actually make bare except: *more* likely to be used, which is contrary
> to the intention.  Maybe we should just get rid of it, and encourage
> people to write
> 
>     except Exception:
> 
> or
> 
>     except Raisable:
> 
> depending on what they want.
> 

Fine by me.  I would just make sure that it is suggested people
typically catch Exception most of the time and discourage direct
catching of Raisable unless they know what they are doing.

> > MacError
> > UnixError
> 
> Do we really need these?  Let's not add things that won't be used.
> 

Is WindowsError used enough to warrant its existence?

> > NamespaceException
> >
> > To provide a common superclass for exceptions dealing with namespace
> > issues, this exception is introduced.
> > Both UnboundLocalError and UnboundGlobalError (the new name for
> > NameError) inherit from this class.
> 
> OTOH there's something to say to unify NameError and AttributeError,
> isn't there?

Somewhat.  You could say that an object is just its own namespace. 
But I don't see a strong enough correlation to warrant the merging. 
Or you just saying we should rename AttributeError to NameError?

> > EnvironmentError
> >
> > Originally meant as an exception for when an event outside of the
> > interpreter needed to raise an exception, its use has been deemed
> > unneeded.
> > While both IOError and OSError inherited this class, the distinction
> > between OS and I/O is significant enough to not warrant having a
> > common subclass that one might base an ``except`` clause on.
> 
> -1000.  Depending on whether you use open() or os.open() you'll get
> one or the other for pretty much the same thing.
> 

But it doesn't have to stay that way.  This is Python 3.0 we are
talking about, so we can change how both work.

But if you want to keep EnvironmentError that's fine.

> Also, I think that socket.error and select.error should inherit from
> EnvironmentError (or maybe even from OSError).
> 

Shouldn't the former inherit from IOError?

> > RuntimeError
> 
> > Meant to be used when an existing exception does not fit, its
> > usefulness is consider meager in Python 2.4 [exceptionsmodule]_.
> > Also, with the CriticalException/Exception dichotomy, Exception or
> > CriticalException can be raised directly for the same use.
> 
> -0.5.  I use it all the time as the "application" exception in apps
> (scripts) that are too small to define their own exception hierarchy.
> 

How about GenericException?  I just don't think RuntimeError is quite
the right name for this.

> > StopIteration and GeneratorExit
> >
> > Inherit from ControlFlowException.
> >
> > Collecting all control flow-related exceptions under a common
> > superclass continues with the theme of maintaining a hierarchy.
> 
> Yes, but how useful it this?  I don't expect to ever come across a
> situation where I'd want to catch both, so this is more for
> organization of the docs than for anything else.
> 
> IMO a good principle for determining the ideal exception hierarchy is
> whether there's a use case for catching the common base class.
> 

Well, Robert says there is a use case in CherryPy.

> > IOError
> >
> > No longer subclasses EnvironmentError.
> 
> -1000, see above.
> 
> > Change the Name of Raisable?
> >
> > It has been argued that Raisable is a bad name to use since it is not
> > an actual word [python-dev1]_.
> 
> Then we'll make it a word.  Is Java's equivalent, Throwable, any more
> a word?  In this case I like the parallel with Java.
> 

Fine by me.

> > Should Bare ``except`` Clauses be Removed?
> 
> Yes, see above.
> 

OK.

-Brett

From bcannon at gmail.com  Sat Jul 30 09:58:20 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 00:58:20 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
References: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
Message-ID: <bbaeab100507300058ce5eda5@mail.gmail.com>

On 7/29/05, Robert Brewer <fumanchu at amor.org> wrote:
> Brett Cannon wrote:
> > New Hierarchy
> > =============
> >
> > Raisable (new; rename BaseException?)
> > +-- CriticalException (new)
> >     +-- KeyboardInterrupt
> >     +-- MemoryError
> >     +-- SystemExit
> >     +-- SystemError (subclass SystemExit?)
> 
> I'd recommend not subclassing SystemExit--there are too many programs
> out there which expect the argument (e.g. sys.exit(3)) to mean something
> specific, but that expectation doesn't apply at all to SystemError.
> 

Don't forget this is Python 3.0; if it makes more sense we can break code.

> > +-- Exception (replaces StandardError)
> >...
> >     +-- ControlFlowException (new)
> 
> I'd definitely appreciate ControlFlowException--there are a number of
> exceptions in CherryPy which should subclass from that. Um, CherryPy
> 3.0, that is. ;)
> 

=)  Well, assuming Guido thinks this is enough of a possible use case.

> >     +-- LookupError (better name?)
> 
> SubscriptError, perhaps? But LookupError could become the "I didn't find
> obj X in the container you specified" superclass, in which case
> LookupError is perfect.
> 

That's what it's meant for and renaming it GetitemError doesn't
exactly clarify it for newbies.  =)  I doubt something better is going
to be found.

> >     +-- TypeError
> >         +-- AttributeError (subclassing new)
> 
> "Since most attribute access errors can be attributed to an object not
> being the type that one expects, it makes sense for AttributeError to
> be considered a type error."
> 
> Very hmmm. I would have thought it would be a LookupError instead, only
> because I favor the duck-typing parts of Python. Making AttributeError
> subclass from TypeError leans toward stronger typing models a bit too
> much, IMO.
> 

This idea has been brought up before on several separate occasions and
this subclassing was what was suggested.

It seems a decision needs to be made as to whether the lack of an
attribute is a failure of using the wrong type of object, just a
failure to find something in an object, or a failure to find a name in
a namespace.  I lean towards the first one, you like the second, and
Guido seems to like the third.  $20 says Guido's opinion in the end
will matter more than ours.  =)

> >     +-- WeakReferenceError (rename for ReferenceError)
> 
> This also has a LookupError feel to it.
> 

Nope, as Fred explains in his own email.

> > It has been argued that Raisable is a bad name to use since it is not
> > an actual word [python-dev1]_.
> 
> Perhaps, but compare http://www.onelook.com/?w=raisable to
> http://www.onelook.com/?w=raiseable. The only sources "raiseable" has
> going for it are Dictionary.com (which aggregates lots of questionable
> sources), Rhymezone, and LookWAYup. I think "raisable" is the clear
> winner.
> 

And Guido seems fine with it, so unless someone can convince Guido
otherwise the PEP will go with Raisable.

-Brett

From bcannon at gmail.com  Sat Jul 30 09:59:12 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 00:59:12 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <ca471dc2050729202220bb1d63@mail.gmail.com>
References: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
	<ca471dc2050729202220bb1d63@mail.gmail.com>
Message-ID: <bbaeab1005073000593910734c@mail.gmail.com>

OK, I withdraw the suggestion of the subclassing of SystemError by SystemExit.

-Brett

On 7/29/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> On 7/29/05, Robert Brewer <fumanchu at amor.org> wrote:
> > >     +-- SystemExit
> > >     +-- SystemError (subclass SystemExit?)
> >
> > I'd recommend not subclassing SystemExit--there are too many programs
> > out there which expect the argument (e.g. sys.exit(3)) to mean something
> > specific, but that expectation doesn't apply at all to SystemError.
> 
> Agreed. SystemExit is used by sys.exit(); SystemError is something
> completely different, used by the interpreter when it finds an
> internal invariant is broken. It is one step short of a fatal error --
> the latter is used when we have evidence of random memory scribbling,
> the former when the interpreter is still intact.
> 
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>

From ncoghlan at gmail.com  Sat Jul 30 10:13:31 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 30 Jul 2005 18:13:31 +1000
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab100507291734337930a2@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
Message-ID: <42EB36AB.30102@gmail.com>

Brett Cannon wrote:
>     +-- ControlFlowException (new)

While I like the idea of ControlFlowException as the "one obvious way" to 
break out of multiple nested loops, I'm not convinced StopIteration and 
GeneratorExit should be inheriting from it.

However, I'm even less sure StopIteration and GeneratorExit should be in the 
Exception portion of the hierarchy at all. This is particularly true of 
GeneratorExit - I would be very concerned if "except Exception:" were to 
suppress GeneratorExit. If ControlFlowException was moved up to be a peer of 
Exception, I'd be much happier with the idea - we would then have four major 
categories of raisable classes:
   CriticalException - something is seriously wrong
   ControlFlowException - an exception is being used to affect control flow in 
a particular way, and should be intercepted only if you know what that control 
flow is doing
   Exception - your every day, run of the mill, exceptions
   Warning - not really an exception.

>         +-- GeneratorExit (introduced by PEP 342 [PEP342]_; subclass
> StopIteration?)

Definitely not. GeneratorExit was added because the following idiom prevents 
the use of StopIteration or a subclass to reliably terminate a generator:

   try:
     yield itr.next()
   catch StopIteration:
     pass

>     +-- LookupError (better name?)
>         +-- IndexError
>         +-- KeyError

I don't think there is a particularly strong argument to change the name of 
LookupError. While Py3K *allows* backwards incompatibility, we shouldn't be 
gratutitous about it.

>     +-- TypeError
>         +-- AttributeError (subclassing new)
>     +-- NamespaceException (new)
>         +-- UnboundGlobalError (new name for NameError)
>         +-- UnboundLocalError (no longer subclasses UnboundGlobalError
> which replaces NameError)

I'd actually be inclined to make AttributeError a subclass of NameError:

   +-- NameError
       +-- AttributeError (subclassing new)
       +-- UnboundGlobalError (new)
       +-- UnboundLocalError

Current uses of NameError are replaced with UnboundGlobalError. The re-use of 
NameError reduces the backwards incompatibility, and also concisely summarises 
the common feature of these three exceptions.

> RuntimeError
> ''''''''''''
> Meant to be used when an existing exception does not fit, its
> usefulness is consider meager in Python 2.4 [exceptionsmodule]_.
> Also, with the CriticalException/Exception dichotomy, Exception or
> CriticalException can be raised directly for the same use.

Like Guido, I believe RuntimeError is very useful for quick-and-dirty scripts. 
Also, gratuitous incompatibility should be avoided, even for Py3k.

> Change the Name of Raisable?
> ----------------------------
> 
> It has been argued that Raisable is a bad name to use since it is not
> an actual word [python-dev1]_.
> At issue is choosing a name that clearly explains the class' usage.
> "BaseException" might be acceptable although the name does not quite
> make it as explicit as Raisable that the class is not meant to be
> raised directly.

I like Raisable, because it states exactly what the base class indicates: 
something which can be raised (i.e., used with the "raise" statement). I'm 
also unclear on why anyone would say it isn't an actual word:

http://dictionary.reference.com/search?q=raisable

> Should Bare ``except`` Clauses be Removed?
> ------------------------------------------
I think Explicit Is Better Than Implicit for this one - a bare except which is 
not the equivalent of "except Raisable" would be quite confusing.

So long as the tutorial says that anything broader then "except Exception" is 
going to be wrong 99.9% of the time, I don't think there will be a problem.

> Change the name of Exception?
> -----------------------------

Again, there is a strong backwards compatibility argument for keeping the name 
Exception for the "this is what you should normally catch" category. Mainly, 
there's a lot of code out there that already uses it this way. Without a 
compelling argument in favour of a different name, stick with Exception.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From ncoghlan at gmail.com  Sat Jul 30 10:41:51 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 30 Jul 2005 18:41:51 +1000
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab100507300058ce5eda5@mail.gmail.com>
References: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
	<bbaeab100507300058ce5eda5@mail.gmail.com>
Message-ID: <42EB3D4F.1090207@gmail.com>

Brett Cannon wrote:
> On 7/29/05, Robert Brewer <fumanchu at amor.org> wrote:
> 
>>Brett Cannon wrote:
>>
>>>New Hierarchy
>>>=============
>>>
>>>Raisable (new; rename BaseException?)
>>>+-- CriticalException (new)
>>>    +-- KeyboardInterrupt
>>>    +-- MemoryError
>>>    +-- SystemExit
>>>    +-- SystemError (subclass SystemExit?)
>>
>>I'd recommend not subclassing SystemExit--there are too many programs
>>out there which expect the argument (e.g. sys.exit(3)) to mean something
>>specific, but that expectation doesn't apply at all to SystemError.
>>
> 
> 
> Don't forget this is Python 3.0; if it makes more sense we can break code.

True, but we should still have a decent reason to break stuff. One other thing 
to keep in mind is that it is easy to handle multiple exception classes with a 
single except clause - what is hard to fix in user code is inappropriate 
inheritance between exceptions (cases where you want to 'catch most instances 
of this class, but not instances of this particular subclass').

>>>+-- Exception (replaces StandardError)
>>>...
>>>    +-- ControlFlowException (new)
>>
>>I'd definitely appreciate ControlFlowException--there are a number of
>>exceptions in CherryPy which should subclass from that. Um, CherryPy
>>3.0, that is. ;)
>>
> 
> 
> =)  Well, assuming Guido thinks this is enough of a possible use case.

Or if he can be persuaded that ControlFlowException should exist as a peer of 
Exception and CriticalException. . .

>>>    +-- TypeError
>>>        +-- AttributeError (subclassing new)
>>
>>"Since most attribute access errors can be attributed to an object not
>>being the type that one expects, it makes sense for AttributeError to
>>be considered a type error."
>>
>>Very hmmm. I would have thought it would be a LookupError instead, only
>>because I favor the duck-typing parts of Python. Making AttributeError
>>subclass from TypeError leans toward stronger typing models a bit too
>>much, IMO.
>>
> 
> This idea has been brought up before on several separate occasions and
> this subclassing was what was suggested.
> 
> It seems a decision needs to be made as to whether the lack of an
> attribute is a failure of using the wrong type of object, just a
> failure to find something in an object, or a failure to find a name in
> a namespace.  I lean towards the first one, you like the second, and
> Guido seems to like the third.  $20 says Guido's opinion in the end
> will matter more than ours.  =)

I think this is a context thing - whether or not an AttributeError is a 
TypeError or LookupError depends on the situation.

In ducktyping, attributes are used to determine if the object is of the 
correct type. In this case, an AttributeError indicates a TypeError.

However, it isn't that uncommon to use an instance's namespace like a 
dictionary to avoid typing lots of square brackets and quotes (e.g. many 
configuration handling modules work this way). In this case, an AttributeError 
indicates a LookupError.

I think it's similar to the common need to convert from KeyError to 
AttributeError in __getattr__ methods - the extra attributes are looked up in 
some other container, and the resultant KeyError needs to be converted to an 
AttributeError by the __getattr__ method. That common use case still doesn't 
mean KeyError should subclass AttributeError.

On the other hand, an AttributeError is _always_ a failure to find a name in a 
namespace (an instance namespace, rather than locals or globals), so having it 
inherit from NameError is a reasonable idea.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From mal at egenix.com  Sat Jul 30 12:33:19 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 30 Jul 2005 12:33:19 +0200
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab100507291734337930a2@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
Message-ID: <42EB576F.3060309@egenix.com>

Brett Cannon wrote:
> Well, it has been discussed at multiple times in the past and I have
> promised to write this PEP several times, so I finally found enough
> time to write a PEP on reorganizing exceptions for Python 3.0 .
> 
> Key points in this PEP is the reworking the hierarchy, requiring
> anything raised to inherit from a certain superclass, and to change
> bare 'except' clauses to catch a specific superclass.  The first and
> last points I expect some contention, but the middle point I expect
> people are okay with (Guido liked the idea when Paul Prescod brought
> it up and the only person who didn't like it, Holger, ended up being
> okay with it when the superclass had a reasonable name).

I'm not sure what you meant with "the middle", but if this
refers to the renaming and reordering of the exception
inheritance tree, you can have my -1 on this.

I don't have any problem with making all exception inherit
from Exception and disallowing bare except clauses.

So that's a bit inverse of what you've obviously expected :-)

The reason for my -1 on the renaming and reordering is
that it would completely break compatibility of Python 2.x
applications with Python 3. Furthermore, there would be next to
no chance of writing new applications that run in Python 3
and 2, so you have breakage in both directions.

Whether this is desired or not is a different discussion,
I just want to point out some important things to consider:

When moving from Python 2.x to 3.0, renaming could be solved
with the help of some scripts, grep et al. However, there
would have to be a good reason for each of these renamings,
otherwise this only introduces additional porting overhead.
Aliases might be a way to provide soft introduction.

Something that scripts will not be able to help with are
changes in the inheritance tree, e.g. if an application
catches a ValueError, the programmer might also expect
UnicodeErrors to get caught, if the application catches
a TypeError, this may not be aware that the TypeError could
actually be an AttributeError.

Many applications define their own exception classes
which then normally inherit from StandardError. In the
application itself, you'd then usually use StandardError
for the generic "catch-all except SystemExit" try-excepts.
With the new hierarchy, catching Exception (renamed from
StandardError) would let e.g. AssertionErrors, SyntaxErrors,
etc. that may well have been produced by debugging code
or calls to compile() pass through.

Since exceptions are also used in the interpreter itself
for masking certain situations and, of course, in the
gazillion 3rd party extensions out there, your proposed
change would also have to be applied to C code - where
finding such subtleties is even harder than in plain
Python.

This is all fine, if we really intend to go for complete
breakage and basically require that Python 3 applications
need to be written from scratch.

I, for one, don't find the existing exception structure
all too bad. It has worked for me for many many years
without ever having a true need to work around some
quirks in the hierarchy. I've had these issues with some
3rd party extensions using the existing Exception class
as base-class for their own error classes in cases where
a StandardError inheritance would have been much more
appropriate, but even there, listing the exceptions
in a tuple has so far always helped.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 30 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From mal at egenix.com  Sat Jul 30 12:38:09 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 30 Jul 2005 12:38:09 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <1122676547.10752.61.camel@geddy.wooz.org>
References: <42E93940.6080708@v.loewis.de> <42EA061A.9040609@egenix.com>	
	<42EA98CC.4060003@v.loewis.de>
	<1122676547.10752.61.camel@geddy.wooz.org>
Message-ID: <42EB5891.6020008@egenix.com>

Barry Warsaw wrote:
> On Fri, 2005-07-29 at 16:59, "Martin v. L?wis" wrote:
> 
> 
>>Perhaps. Somebody would need to research the precise migration
>>procedure. I once tried to move the Python CVS to Sunsite
>>(or its successors), and gave up after half a year of getting
>>nowhere; I'm personally not keen on repeating such an experience.
> 
> 
> I'm with you.  SF is a devil we know.  If we don't stick with them (and
> it looks like that's not an option if we want to switch to svn soon),
> then I say we move it to svn.python.org, where we already have a server
> set up and running.  If we need more volunteers, well the community has
> always stepped up before and I'm sure it will when we come asking again.
> 
> Actually, it's a good idea to /always/ be soliciting for help.  People
> get burned out and busy and I'd love to have a bullpen of volunteers
> that gets constantly refreshed.

I guess my point in suggesting a company to do the hosting was
to overcome any issues with people getting burned or tired of
administration.

The PSF does have a reasonable budget, so why not use it to
maintain the infrastructure needed for Python development and
let a company do the administration of the needed servers and
the importing of the CSV and tracker items into their
systems ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 30 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

From martin at v.loewis.de  Sat Jul 30 12:47:45 2005
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 30 Jul 2005 12:47:45 +0200
Subject: [Python-Dev] PEP: Migrating the Python CVS to Subversion
In-Reply-To: <42EB5891.6020008@egenix.com>
References: <42E93940.6080708@v.loewis.de> <42EA061A.9040609@egenix.com>	
	<42EA98CC.4060003@v.loewis.de>
	<1122676547.10752.61.camel@geddy.wooz.org>
	<42EB5891.6020008@egenix.com>
Message-ID: <42EB5AD1.60703@v.loewis.de>

M.-A. Lemburg wrote:
 > The PSF does have a reasonable budget, so why not use it to
 > maintain the infrastructure needed for Python development and
 > let a company do the administration of the needed servers and
 > the importing of the CSV and tracker items into their
 > systems ?

In principle, this might be a good idea. In practice, it falls
short of details: which company, what precisely are their procedures,
etc. It's not always the case that giving money to somebody really
gives you back the value you expect.

Regards,
Martin


From pedronis at strakt.com  Sat Jul 30 13:20:50 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Sat, 30 Jul 2005 13:20:50 +0200
Subject: [Python-Dev] Next PyPy sprint: Heidelberg (Germany),
	22nd-29th of August
Message-ID: <42EB6292.5080301@strakt.com>

PyPy Sprint in Heidelberg 22nd - 29th August 2005
==================================================

The next PyPy sprint will take place at the Heidelberg University
in Germany from 22nd August to 29th August (both days included).
Its main focus is translation of the whole PyPy interpreter
to a low level language and reaching 2.4.1 Python compliancy.
To learn more about the new PyPy Python implementation
look here:

     http://codespeak.net/pypy


Goals and topics of the sprint
------------------------------

One of the main goals of the sprint is going to be a 0.7 release of
PyPy. The 0.7 is meant to be the first self-contained PyPy version but
still alpha with some C-extension modules missing and not meant for
production use.

Therefore the topics of the sprint will be:

    - translation efforts: it's not completely clear now what related
      task will be left at that time
    - work on 2.4.1 compliancy: there are some failing compliancy tests
      on which we plan to work
    - rewriting c-extension modules/integrating existing rewrites
    - all kinds of small release issues
    - possibly some more LLVM efforts


Location & Accomodation
------------------------

The sprint will be held in a conference room of the Institute of
Physics, University of Heidelberg. We have WLAN connection there and
small kitchen to make tea and coffee. `See here`_ how to get there from
the Heidelberg main station.

There is a huge number of hotels_ in Heidelberg, all of which are
unfortunately rather expensive. It should be no problem to reach the
sprint venue from anywhere in Heidelberg. As an alternative you could
also take a `hotel in Mannheim`_ which you can reach in 15 min from
Heidelberg with the train.

.. _`See here`:
http://www.physi.uni-heidelberg.de/physi/front/anfahrt.en.php
.. _hotels: http://www.cvb-heidelberg.de/index_eng.html
.. _`hotel in Mannheim`: http://www.hotels.de/en/mannheim.htm

Exact times
-----------

The Pypy sprint is held Monday 22nd August - Monday 29th August 2005.
Hours will be from 09:00 until people have had enough. It's a good
idea to arrive a day before the sprint starts.


Network, Food
-------------

The Heidelberg Altstadt can be reached in approximately 10 min from the
sprint venue. There you will find all kinds of restaurants and fast food
places.

You will probably need a wireless network card to access the network
although we could set up a WLAN to cable bridge if necessary.


Registration etc.pp.
--------------------

Please subscribe to the `PyPy sprint mailing list`_, introduce
yourself and post a note that you want to come.  Feel free
to ask any questions there!  There also is a separate
`Heidelberg people`_ page tracking who is already thought
to come.  If you have commit rights on codespeak then
you can modify yourself a checkout of


http://codespeak.net/svn/pypy/extradoc/sprintinfo/heidelberg-people.txt

.. _`Heidelberg people`:
http://codespeak.net/pypy/index.cgi?extradoc/sprintinfo/heidelberg-people.html 


.. _`PyPy sprint mailing list`:
http://codespeak.net/mailman/listinfo/pypy-sprint

--
Samuele Pedroni & the PyPy team

From foom at fuhm.net  Sat Jul 30 14:37:15 2005
From: foom at fuhm.net (James Y Knight)
Date: Sat, 30 Jul 2005 08:37:15 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
References: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
Message-ID: <B3AAF48A-2D68-45A4-B713-C696EBBAC50F@fuhm.net>

On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote:

> I'd recommend not subclassing SystemExit--there are too many programs
> out there which expect the argument (e.g. sys.exit(3)) to mean  
> something
> specific, but that expectation doesn't apply at all to SystemError.

Yes please make note of this for *all* exception (and otherwise)  
inheritance. You must ensure that any exception B that inherits from  
A conforms to A's interface! If that isn't the case, it shouldn't  
inherit. Lots of people seem to forget this, and it's always a pain  
in the ass.

James

From ncoghlan at gmail.com  Sat Jul 30 15:43:30 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 30 Jul 2005 23:43:30 +1000
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EB576F.3060309@egenix.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
Message-ID: <42EB8402.10902@gmail.com>

M.-A. Lemburg wrote:
> The reason for my -1 on the renaming and reordering is
> that it would completely break compatibility of Python 2.x
> applications with Python 3. Furthermore, there would be next to
> no chance of writing new applications that run in Python 3
> and 2, so you have breakage in both directions.
> 
> Whether this is desired or not is a different discussion,
> I just want to point out some important things to consider:
> 
> When moving from Python 2.x to 3.0, renaming could be solved
> with the help of some scripts, grep et al. However, there
> would have to be a good reason for each of these renamings,
> otherwise this only introduces additional porting overhead.
> Aliases might be a way to provide soft introduction.
> 
> Something that scripts will not be able to help with are
> changes in the inheritance tree, e.g. if an application
> catches a ValueError, the programmer might also expect
> UnicodeErrors to get caught, if the application catches
> a TypeError, this may not be aware that the TypeError could
> actually be an AttributeError.

I think the problems with this can be minimised by avoiding making changes we 
don't need to. I think only a few changes are needed to get a significantly 
cleaner structure.

Here's a fairly minimal proposal, which is closer to the existing 2.4 structure:

New Hierarchy
=============

Raisable (formerly Exception)
+-- CriticalException (new)
     +-- KeyboardInterrupt
     +-- MemoryError
     +-- SystemError
+-- ControlFlowException (new)
     +-- GeneratorExit
     +-- StopIteration
     +-- SystemExit
+-- Exception (formerly StandardError)
     +-- AssertionError
     +-- AttributeError
     +-- ImportError
     +-- TypeError
     +-- WeakReferenceError (formerly ReferenceError)
     +-- ArithmeticError
         +-- FloatingPointError
         +-- DivideByZeroError
         +-- OverflowError
     +-- EnvironmentError
         +-- OSError
             +-- WindowsError (possibly remove this from builtins)
         +-- IOError
             +-- EOFError
     +-- LookupError
         +-- IndexError
         +-- KeyError
     +-- NameError
         +-- UnboundLocalError
     +-- RuntimeError
         +-- NotImplementedError
     +-- SyntaxError
         +-- IndentationError
             +-- TabError
     +-- ValueError
         +-- UnicodeError
             +-- UnicodeDecodeError
             +-- UnicodeEncodeError
             +-- UnicodeTranslateError
+-- Warning
     +-- DeprecationWarning
     +-- FutureWarning
     +-- PendingDeprecationWarning
     +-- SemanticsWarning (formerly RuntimeWarning)
     +-- SyntaxWarning
     +-- UserWarning

Changes from Py 2.4:
====================

The big changes:

   Exception renamed to Raisable
   StandardError renamed to Exception
     Rationale for this renaming is that too many people do "except 
Exception:" when they really mean "except StandardError:". Most applications 
should cope with this semantics change without much hassle, as the only 
exceptions that "slip through the net" are KeyboardInterrupt, MemoryError and 
SystemError.

   New exception ControlFlowException
   Make SystemExit a subclass of this
   Make StopIteration a subclass of this
   Make GeneratorExit a subclass of this
     In Python 2.4, the only two exceptions not under StandardError are 
SystemExit and StopIteration. These are both control flow exceptions - one 
indicates termination of the application, the other indicates completion of an 
iterator. Python 2.5 will most likely add GeneratorExit for termination of a 
generator.
     Grouping these under a common superclass has a few benefits.
       - documentation benefit (its obvious why these exceptions are special)
       - OOWTDI for breaking out of nested loops: raise and catch CFE
       - module developers can use it to clearly mark their own CFE classes

   New exception CriticalException
   Make KeyboardInterrupt a subclass of this
   Make MemoryError a subclass of this
   Make SystemError a subclass of this
     All of these exceptions inherit from StandardError in Python 2.4, but 
each of them indicates something is seriously wrong. KI indicates Ctrl-C has 
been pressed, ME indicates the VM has run out of memory, and SE indicates the 
VM's internals are out of whack. There isn't much a program can or should be 
doing about these. Certainly, none of them should be getting caught by "except 
Exception:".

The following changes are comparatively minor cleanups:

   Make EOFError a subclass of IOError
      Trying to read past the end of a file _is_ an IOError!

   ReferenceError renamed to WeakReferenceError
     This recaptures the context that was lost when making this a builtin.

   RuntimeWarning renamed to SemanticsWarning
     This better captures the meaning of the warning, and avoids confusion 
with RuntimeError, which has a very different purpose.


A few key differences from Brett's original proposal:

   I severely culled the Critical Exceptions list. The CE list was dropped 
back to those where either the user has indicated they want the program to 
stop, or the VM has reported that there is a severe problem. Everything else 
went back under Exception.

   ControlFlowException was made a peer category to Exception and 
CriticalException. This preserves the location of StopIteration. I also added 
SystemExit to this group, because it relates to control flow of the entire 
application (i.e., it is the graceful way to say "get out now").

   AttributeError is left as a standalone exception.

   NameError is not renamed as it actually indicates:
     - this name is not in locals
     - this name is not in any containing lexical scope
     - this name is not in the module globals
     - this name is not in builtins
   UnboundLocalError indicates "this name is in locals, but was referenced 
before it was set". So, I'm not sure what UnboundGlobalError would actually 
_mean_.

   Various other exceptions (RuntimeError, EnvironmentError, etc) either 
weren't deleted or weren't moved. The changes I kept had decent justifications 
for how they improved the clarity of the exception structure - those I dropped 
were those I haven't found convincing.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From jack at performancedrivers.com  Sat Jul 30 17:20:33 2005
From: jack at performancedrivers.com (Jack Diederich)
Date: Sat, 30 Jul 2005 11:20:33 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EB3D4F.1090207@gmail.com>
References: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
	<bbaeab100507300058ce5eda5@mail.gmail.com>
	<42EB3D4F.1090207@gmail.com>
Message-ID: <20050730152033.GL4840@performancedrivers.com>

On Sat, Jul 30, 2005 at 06:41:51PM +1000, Nick Coghlan wrote:
> Brett Cannon wrote:
> > Don't forget this is Python 3.0; if it makes more sense we can break code.
> 
> Or if he can be persuaded that ControlFlowException should exist as a peer of 
> Exception and CriticalException. . .
> 
> >>>    +-- TypeError
> >>>        +-- AttributeError (subclassing new)
> >
> > It seems a decision needs to be made as to whether the lack of an
> > attribute is a failure of using the wrong type of object, just a
> > failure to find something in an object, or a failure to find a name in
> > a namespace.  I lean towards the first one, you like the second, and
> > Guido seems to like the third.  $20 says Guido's opinion in the end
> > will matter more than ours.  =)
> 
> I think this is a context thing - whether or not an AttributeError is a 
> TypeError or LookupError depends on the situation.
> 
> In ducktyping, attributes are used to determine if the object is of the 
> correct type. In this case, an AttributeError indicates a TypeError.

+1

> However, it isn't that uncommon to use an instance's namespace like a 
> dictionary to avoid typing lots of square brackets and quotes (e.g. many 
> configuration handling modules work this way). In this case, an AttributeError 
> indicates a LookupError.

I expect any square-brackets (foo['bar'] or foo[7]) to be a LookupError or
a subclass (KeyError, IndexError).  If AttributeError subclassed LookupError
you would have to work around it in common code where you are accessing
an attribute and doing a [] lookup on the same line.

class Foo(object):
  bar = {'k' : ['A', 'B', 'C']}

try:
  print Foo.barrr['j'][7] # could raise AttributeError, IndexError, KeyError
except (KeyError, IndexError): pass

If the attribute isn't there I made a coding mistake, if the key/index isn't
there my data source doesn't include that item (not a mistake, it just isn't 
there).

> I think it's similar to the common need to convert from KeyError to 
> AttributeError in __getattr__ methods - the extra attributes are looked up in 
> some other container, and the resultant KeyError needs to be converted to an 
> AttributeError by the __getattr__ method. That common use case still doesn't 
> mean KeyError should subclass AttributeError.

The top level access should dictate which error it raises, even if attributes
are implemented with dictionaries. 'foo.bar' and 'foo.__dict__['bar']' look
different to me, even if the results on success are frequently the same.

Any chance str.index and list.index could raise IndexError instead of
ValueError in 3.0?  Even after a few years of using them I still get this
wrong.  index() isn't the same lookup as [], but my brain still slips and
expects a function named "index" to raise an "IndexError"

-jackdied

From aahz at pythoncraft.com  Sat Jul 30 19:04:47 2005
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 30 Jul 2005 10:04:47 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EB8402.10902@gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com> <42EB8402.10902@gmail.com>
Message-ID: <20050730170446.GA12163@panix.com>

On Sat, Jul 30, 2005, Nick Coghlan wrote:
>
> I think the problems with this can be minimised by avoiding making
> changes we don't need to. I think only a few changes are needed to get
> a significantly cleaner structure.
>
> Here's a fairly minimal proposal, which is closer to the existing 2.4
> structure:

Based on skimming (not close examination): +1

We can probably quibble about bits, but I agree that a Grand Restructure
should be avoided.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.

From exogen at gmail.com  Sat Jul 30 19:56:20 2005
From: exogen at gmail.com (Brian Beck)
Date: Sat, 30 Jul 2005 13:56:20 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EB8402.10902@gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>	<42EB576F.3060309@egenix.com>
	<42EB8402.10902@gmail.com>
Message-ID: <dcgevq$1oo$1@sea.gmane.org>

Nick Coghlan wrote:
> Here's a fairly minimal proposal, which is closer to the existing 2.4 structure:
> 
> New Hierarchy
> ...

I also like this version.

-- 
Brian Beck
Adventurer of the First Order


From bcannon at gmail.com  Sat Jul 30 21:02:30 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 12:02:30 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EB36AB.30102@gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB36AB.30102@gmail.com>
Message-ID: <bbaeab10050730120271810977@mail.gmail.com>

On 7/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
> >     +-- ControlFlowException (new)
> 
> While I like the idea of ControlFlowException as the "one obvious way" to
> break out of multiple nested loops, I'm not convinced StopIteration and
> GeneratorExit should be inheriting from it.
> 
> However, I'm even less sure StopIteration and GeneratorExit should be in the
> Exception portion of the hierarchy at all. This is particularly true of
> GeneratorExit - I would be very concerned if "except Exception:" were to
> suppress GeneratorExit. If ControlFlowException was moved up to be a peer of
> Exception, I'd be much happier with the idea - we would then have four major
> categories of raisable classes:
>    CriticalException - something is seriously wrong
>    ControlFlowException - an exception is being used to affect control flow in
> a particular way, and should be intercepted only if you know what that control
> flow is doing
>    Exception - your every day, run of the mill, exceptions
>    Warning - not really an exception.
>

I can live with this.  I was waivering on putting ControlFlowException
under CriticalException, but obviously keeping that dichotomy was more
important back when bare 'except' clauses were going to be allowed,
but now that it looks like they are being removed I am much more open
to putting stuff to inherit directly from Raisable.
 
> >         +-- GeneratorExit (introduced by PEP 342 [PEP342]_; subclass
> > StopIteration?)
> 
> Definitely not. GeneratorExit was added because the following idiom prevents
> the use of StopIteration or a subclass to reliably terminate a generator:
> 
>    try:
>      yield itr.next()
>    catch StopIteration:
>      pass
> 

Good enough for me.

> >     +-- LookupError (better name?)
> >         +-- IndexError
> >         +-- KeyError
> 
> I don't think there is a particularly strong argument to change the name of
> LookupError. While Py3K *allows* backwards incompatibility, we shouldn't be
> gratutitous about it.
> 

It looks like the backwards-compatilibity gods are starting to stomp
on me; I can sacrifice a renaming to appease them.

> >     +-- TypeError
> >         +-- AttributeError (subclassing new)
> >     +-- NamespaceException (new)
> >         +-- UnboundGlobalError (new name for NameError)
> >         +-- UnboundLocalError (no longer subclasses UnboundGlobalError
> > which replaces NameError)
> 
> I'd actually be inclined to make AttributeError a subclass of NameError:
> 
>    +-- NameError
>        +-- AttributeError (subclassing new)
>        +-- UnboundGlobalError (new)
>        +-- UnboundLocalError
> 
> Current uses of NameError are replaced with UnboundGlobalError. The re-use of
> NameError reduces the backwards incompatibility, and also concisely summarises
> the common feature of these three exceptions.
> 

Hmm.  Well, I think it was either Tim or Barry (or both) who once
suggested AttributeError inherit from TypeError, but they have not
spoken up nor has anyone else so far supporting the idea.

But then again people have argued for LookupError instead.  I am going
to have to think about this one before I attempt to reply on this
topic.

> > RuntimeError
> > ''''''''''''
> > Meant to be used when an existing exception does not fit, its
> > usefulness is consider meager in Python 2.4 [exceptionsmodule]_.
> > Also, with the CriticalException/Exception dichotomy, Exception or
> > CriticalException can be raised directly for the same use.
> 
> Like Guido, I believe RuntimeError is very useful for quick-and-dirty scripts.
> Also, gratuitous incompatibility should be avoided, even for Py3k.
> 

OK, but is the name so great?  Yes, it is a runtime error, but it just
doesn't hit the point of it being a dirty little exception to use when
you don't want to create a new one.  How about GenericException or
SimpleException?

Or are the backwards-compatibility gods going to smack me again for
this suggestion and spout something off containing the words "not" and
"Perl 6"?  =)

> > Change the Name of Raisable?
> > ----------------------------
> >
> > It has been argued that Raisable is a bad name to use since it is not
> > an actual word [python-dev1]_.
> > At issue is choosing a name that clearly explains the class' usage.
> > "BaseException" might be acceptable although the name does not quite
> > make it as explicit as Raisable that the class is not meant to be
> > raised directly.
> 
> I like Raisable, because it states exactly what the base class indicates:
> something which can be raised (i.e., used with the "raise" statement). I'm
> also unclear on why anyone would say it isn't an actual word:
> 
> http://dictionary.reference.com/search?q=raisable
> 

I think the point was it was not in someone's spell checker.  But I
consider this point settled since Guido said he was fine with creating
a new word.

> > Should Bare ``except`` Clauses be Removed?
> > ------------------------------------------
> I think Explicit Is Better Than Implicit for this one - a bare except which is
> not the equivalent of "except Raisable" would be quite confusing.
> 
> So long as the tutorial says that anything broader then "except Exception" is
> going to be wrong 99.9% of the time, I don't think there will be a problem.
> 

This seems to be the running consensus so far.  I am expecting bare
'except' clauses to not be allowed.

> > Change the name of Exception?
> > -----------------------------
> 
> Again, there is a strong backwards compatibility argument for keeping the name
> Exception for the "this is what you should normally catch" category. Mainly,
> there's a lot of code out there that already uses it this way. Without a
> compelling argument in favour of a different name, stick with Exception.
> 

Fine by me.  I only tossed that in since originally people were
suggesting BaseException or SafeException and the ilk.

-Brett

From pje at telecommunity.com  Sat Jul 30 21:04:05 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 30 Jul 2005 15:04:05 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python  3.0
In-Reply-To: <42EB8402.10902@gmail.com>
References: <42EB576F.3060309@egenix.com>
	<bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
Message-ID: <5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>

At 11:43 PM 7/30/2005 +1000, Nick Coghlan wrote:
>Here's a fairly minimal proposal, which is closer to the existing 2.4 
>structure:
>
>New Hierarchy
>=============
>
>Raisable (formerly Exception)
>+-- CriticalException (new)
>      +-- KeyboardInterrupt
>      +-- MemoryError
>      +-- SystemError
>+-- ControlFlowException (new)
>      +-- GeneratorExit
>      +-- StopIteration
>      +-- SystemExit
>+-- Exception (formerly StandardError)
>      +-- AssertionError
>      +-- AttributeError
>      +-- ImportError
>      +-- TypeError
>      +-- WeakReferenceError (formerly ReferenceError)

I like this a lot, and a good bit of it could actually be done in 2.5, 
apart from the Exception/StandardError move, assuming also that the renamed 
errors were also available under their old names.  We could probably go so 
far as to add Raisable to the hierarchy, but I don't think we could 
actually get quite to your proposed structure without breaking any 
programs.  On the other hand, if we introduce CriticalException and 
ControlFlowException in 2.5 (inheriting from Exception), and create a new 
Error base for StandardError, then promote subclassing and catching it 
instead of Exception, then there will be less to do in 3.0.  So, my 
thoughts for the 2.x series are:


    Exception
       CriticalException
       ControlFlowException
       Error
          StandardError

with the children of these being as you've proposed.  Now, "except Error:" 
would be the replacement for a bare except in most cases, and we would 
recommend subclassing one of the three Exception subclasses instead of 
Exception itself, maybe even introduce a PendingDeprecationWarning for 
direct Exception subclasses outside the exceptions module, with a 
DeprecationWarning in 2.6 and beyond.

Note that subclassing Error instead of Exception won't hurt any programs 
that already catch Exception, and if they have to deal with libraries that 
haven't made the move, they can always use this pattern:

     except (CriticalException,ControlFlowException):
         raise
     except:
         # whatever


From bcannon at gmail.com  Sat Jul 30 21:17:44 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 12:17:44 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EB576F.3060309@egenix.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
Message-ID: <bbaeab100507301217532e0b85@mail.gmail.com>

On 7/30/05, M.-A. Lemburg <mal at egenix.com> wrote:
> Brett Cannon wrote:
> > Well, it has been discussed at multiple times in the past and I have
> > promised to write this PEP several times, so I finally found enough
> > time to write a PEP on reorganizing exceptions for Python 3.0 .
> >
> > Key points in this PEP is the reworking the hierarchy, requiring
> > anything raised to inherit from a certain superclass, and to change
> > bare 'except' clauses to catch a specific superclass.  The first and
> > last points I expect some contention, but the middle point I expect
> > people are okay with (Guido liked the idea when Paul Prescod brought
> > it up and the only person who didn't like it, Holger, ended up being
> > okay with it when the superclass had a reasonable name).
> 
> I'm not sure what you meant with "the middle",


Actually, it was referencing the bare 'except' clauses and changing
their semantics.

> but if this
> refers to the renaming and reordering of the exception
> inheritance tree, you can have my -1 on this.
> 
> I don't have any problem with making all exception inherit
> from Exception and disallowing bare except clauses.
> 

Do you mean all inherit from Exception in order for it be allowed to
be passed to 'raise'?

> So that's a bit inverse of what you've obviously expected :-)
> 

If this becomes a theme, yes.  But specifically coming from you, MAL,
no, not really.  =)

> The reason for my -1 on the renaming and reordering is
> that it would completely break compatibility of Python 2.x
> applications with Python 3.
> Furthermore, there would be next to
> no chance of writing new applications that run in Python 3
> and 2, so you have breakage in both directions.
> 

My view of Python 3.0 was that backwards-compatibility would not be a
gimme in anyway.  I personally am willing to break stuff in the name
of clarity, which is the point of this whole endeavour.  While I am
willing to back off on some the proposed changes, I do think the basic
spirit of it is correct.

> Whether this is desired or not is a different discussion,
> I just want to point out some important things to consider:
> 
> When moving from Python 2.x to 3.0, renaming could be solved
> with the help of some scripts, grep et al. However, there
> would have to be a good reason for each of these renamings,
> otherwise this only introduces additional porting overhead.
> Aliases might be a way to provide soft introduction.
> 

Right, so the renaming is not a huge problem.

> Something that scripts will not be able to help with are
> changes in the inheritance tree, e.g. if an application
> catches a ValueError, the programmer might also expect
> UnicodeErrors to get caught, if the application catches
> a TypeError, this may not be aware that the TypeError could
> actually be an AttributeError.
> 
> Many applications define their own exception classes
> which then normally inherit from StandardError. In the
> application itself, you'd then usually use StandardError
> for the generic "catch-all except SystemExit" try-excepts.
> With the new hierarchy, catching Exception (renamed from
> StandardError) would let e.g. AssertionErrors, SyntaxErrors,
> etc. that may well have been produced by debugging code
> or calls to compile() pass through.
> 

Right, but if we introduce aliases in Python 2.9 or sooner the
transition will be much easier and they will know to rename things.

And obviously warnings can be used for people to know that the
hierarchy will change.   I bet we will put in a
PendingDeprecationWarning or SemanticsWarning saying that the
inheritance will be different in Python 3.0 .

Yes, this will incur more work than had we left it alone, but the
whole point of Python 3.0 is to remove quirks.

> Since exceptions are also used in the interpreter itself
> for masking certain situations and, of course, in the
> gazillion 3rd party extensions out there, your proposed
> change would also have to be applied to C code - where
> finding such subtleties is even harder than in plain
> Python.
> 

If we fiddle with the exception code raising a Warning will not be too
bad for this.  Plus you can grep for PyExc_TypeError easily enough to
see where you are using classes that have a new inheritance tree.

> This is all fine, if we really intend to go for complete
> breakage and basically require that Python 3 applications
> need to be written from scratch.
> 

I for one don't expect Python 2.x code to run automatically without
some fiddling.  I think saying from scratch is a little strong.

> I, for one, don't find the existing exception structure
> all too bad. It has worked for me for many many years
> without ever having a true need to work around some
> quirks in the hierarchy. I've had these issues with some
> 3rd party extensions using the existing Exception class
> as base-class for their own error classes in cases where
> a StandardError inheritance would have been much more
> appropriate, but even there, listing the exceptions
> in a tuple has so far always helped.
> 

Lot's of things "just work", but it doesn't mean they can't be improved upon.

But it looks like some of my suggestions were overreaching so they
will most likely get scaled back.  I will also add a section to the
PEP discussing how a transition from Python 2.x to Python 3.0 in this
regard can be handled.

-Brett

From bcannon at gmail.com  Sat Jul 30 21:20:49 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 12:20:49 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <B3AAF48A-2D68-45A4-B713-C696EBBAC50F@fuhm.net>
References: <3A81C87DC164034AA4E2DDFE11D258E37726A8@exchange.hqamor.amorhq.net>
	<B3AAF48A-2D68-45A4-B713-C696EBBAC50F@fuhm.net>
Message-ID: <bbaeab1005073012207efafcd1@mail.gmail.com>

On 7/30/05, James Y Knight <foom at fuhm.net> wrote:
> On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote:
> 
> > I'd recommend not subclassing SystemExit--there are too many programs
> > out there which expect the argument (e.g. sys.exit(3)) to mean
> > something
> > specific, but that expectation doesn't apply at all to SystemError.
> 
> Yes please make note of this for *all* exception (and otherwise)
> inheritance. You must ensure that any exception B that inherits from
> A conforms to A's interface! If that isn't the case, it shouldn't
> inherit. Lots of people seem to forget this, and it's always a pain
> in the ass.
> 

The reason for requiring inheriting from Raisable is so that the basic
interface will be guaranteed for any caught exception.  And I don't
think that any of the built-ins have any specific attributes sans
maybe OSError, but that is a leaf in the inheritance tree so that is
not a problem.

Don't worry, the interfaces won't change in the middle of a branch.

-Brett

From bcannon at gmail.com  Sun Jul 31 00:59:38 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 15:59:38 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EB8402.10902@gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com> <42EB8402.10902@gmail.com>
Message-ID: <bbaeab1005073015595854ec8a@mail.gmail.com>

On 7/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> M.-A. Lemburg wrote:
> > The reason for my -1 on the renaming and reordering is
> > that it would completely break compatibility of Python 2.x
> > applications with Python 3. Furthermore, there would be next to
> > no chance of writing new applications that run in Python 3
> > and 2, so you have breakage in both directions.
> >
> > Whether this is desired or not is a different discussion,
> > I just want to point out some important things to consider:
> >
> > When moving from Python 2.x to 3.0, renaming could be solved
> > with the help of some scripts, grep et al. However, there
> > would have to be a good reason for each of these renamings,
> > otherwise this only introduces additional porting overhead.
> > Aliases might be a way to provide soft introduction.
> >
> > Something that scripts will not be able to help with are
> > changes in the inheritance tree, e.g. if an application
> > catches a ValueError, the programmer might also expect
> > UnicodeErrors to get caught, if the application catches
> > a TypeError, this may not be aware that the TypeError could
> > actually be an AttributeError.
> 
> I think the problems with this can be minimised by avoiding making changes we
> don't need to. I think only a few changes are needed to get a significantly
> cleaner structure.
> 
> Here's a fairly minimal proposal, which is closer to the existing 2.4 structure:
> 

Nick, are you going go start subbing in for Tim when he is busy and
take my work that I spent hours on, come up with an alternative that
took 10 minutes, and have everyone end up loving your newfangled idea
10x more than my original?  =)

> New Hierarchy
> =============
> 
> Raisable (formerly Exception)
> +-- CriticalException (new)
>      +-- KeyboardInterrupt
>      +-- MemoryError
>      +-- SystemError
> +-- ControlFlowException (new)

As I have said I am fine with moving ControlFlowException out to here,
but it depends if others agree.

>      +-- GeneratorExit
>      +-- StopIteration
>      +-- SystemExit

Good point with SystemExit!  I am definitely +1 on changing that inheritance.

> +-- Exception (formerly StandardError)
>      +-- AssertionError
>      +-- AttributeError

I am still up for moving AttributeError, but with the amount of
arguing going on between where it should go I am not going to be
shocked if we go with the status quo.

>      +-- ImportError
>      +-- TypeError
>      +-- WeakReferenceError (formerly ReferenceError)
>      +-- ArithmeticError
>          +-- FloatingPointError
>          +-- DivideByZeroError
>          +-- OverflowError
>      +-- EnvironmentError
>          +-- OSError
>              +-- WindowsError (possibly remove this from builtins)

If we are going to lack exceptions for other OSs, I say remove it.  No
reason Windows should get special treatment with a built-in exception.

>          +-- IOError
>              +-- EOFError
>      +-- LookupError
>          +-- IndexError
>          +-- KeyError
>      +-- NameError
>          +-- UnboundLocalError

What about UnboundGlobalError?

>      +-- RuntimeError

I still don't like the name.

>          +-- NotImplementedError

Interesting idea, but I don't view them as the same.  Everyone uses
RuntimeError as a Poor Man's Exception, not as an actual runtime
error.

>      +-- SyntaxError
>          +-- IndentationError
>              +-- TabError
>      +-- ValueError
>          +-- UnicodeError
>              +-- UnicodeDecodeError
>              +-- UnicodeEncodeError
>              +-- UnicodeTranslateError
> +-- Warning
>      +-- DeprecationWarning
>      +-- FutureWarning
>      +-- PendingDeprecationWarning

Don't like the idea of having DeprecationWarning inherit from
PendingDeprecationWarning?

-Brett

From ncoghlan at gmail.com  Sun Jul 31 02:31:41 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 31 Jul 2005 10:31:41 +1000
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab1005073015595854ec8a@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>	
	<42EB576F.3060309@egenix.com> <42EB8402.10902@gmail.com>
	<bbaeab1005073015595854ec8a@mail.gmail.com>
Message-ID: <42EC1BED.2010502@gmail.com>

Brett Cannon wrote:
> Nick, are you going go start subbing in for Tim when he is busy and
> take my work that I spent hours on, come up with an alternative that
> took 10 minutes, and have everyone end up loving your newfangled idea
> 10x more than my original?  =)

It's like editing creative writing - I find it far, far easier to take 
something good and tweak it to make it better, than to come up with something 
good in the first place ;)

>>+-- Exception (formerly StandardError)
>>     +-- AssertionError
>>     +-- AttributeError
> 
> 
> I am still up for moving AttributeError, but with the amount of
> arguing going on between where it should go I am not going to be
> shocked if we go with the status quo.

Exactly my thought. I had it under "NameError" for a while, but had difficulty 
coming up with a case where lumping it in with the lexical scoping errors was 
actually beneficial.

Eventually, the fact that it is easy to add another exception to an except 
clause, but hard to remove a child you don't want that inherits from a parent 
you do want persauded me to leave this one alone.

>>     +-- EnvironmentError
>>         +-- OSError
>>             +-- WindowsError (possibly remove this from builtins)
> 
> 
> If we are going to lack exceptions for other OSs, I say remove it.  No
> reason Windows should get special treatment with a built-in exception.

True. And the interface looks the same as the normal OSError interface, so it 
should be possible to replace all uses with a basic OSError.

>>     +-- NameError
>>         +-- UnboundLocalError
> 
> 
> What about UnboundGlobalError?

I realised this was a misnomer. A failed name lookup actually means:
   - the name was not in locals
   - the name was not in any lexically containing scope
   - the name was not in the module globals
   - the name was not in builtins

The program doesn't know which of those namespaces was *meant* to contain the 
name - it only knows that none of them actually contained it. This criticism 
also applies to the current wording of the NameError text used in this 
situation (which implies the name should have been in the module globals).

Now, a case could possibly be made for separate errors for cases like the 
following:

   def f():
     global x
     print x # UnboundGlobalError (currently NameError, with usual text)

   def f():
     def g():
       print x
     g() # UnboundFreeVariableError (currently NameError, with specific text)
     x = 1

Like UnboundLocalError, in both of these cases, the name is potentially known 
to the compiler - it simply hasn't been bound to anything yet.

>>     +-- RuntimeError
> I still don't like the name.

I'm not that fond of it either - but as the builtin exception most likely to 
be used (abused?) by user code, I expect changing its name would be more pain 
than it's worth.

>>         +-- NotImplementedError
> Interesting idea, but I don't view them as the same.  Everyone uses
> RuntimeError as a Poor Man's Exception, not as an actual runtime
> error.

This particular inheritance is copied from Python 2.4 :)

I find the main trick with making RuntimeError more palatable is to avoid 
thinking of 'runtime' in the sense of 'Python runtime', as in 'Python VM'. 
That's not what this error is about - a Python VM error is a SystemError. 
Instead, a RuntimeError is a generic application error - something which 
happened during happened at program runtime.

Renaming RuntimeWarning to SemanticsWarning should help with that distinction.

>>+-- Warning
>>     +-- DeprecationWarning
>>     +-- FutureWarning
>>     +-- PendingDeprecationWarning
> 
> 
> Don't like the idea of having DeprecationWarning inherit from
> PendingDeprecationWarning?

Not really. Mainly because I'm not sure which way the inheritance should go - 
I could understand someone wanting to suppress PendingDeprecationWarnings 
without suppressing DeprecationWarnings. On the other hand, there's your 
argument that a 'DeprecationWarning is just a PendingDeprecationWarning with a 
shorter timeframe'.

Again, I fell back on the concept that Python's except clause makes it easy to 
ask for both if you want both, but makes it relatively difficult to undo 
exception inheritance if it isn't what you want.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From ncoghlan at gmail.com  Sun Jul 31 02:57:28 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 31 Jul 2005 10:57:28 +1000
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python  3.0
In-Reply-To: <5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>
References: <42EB576F.3060309@egenix.com>
	<bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>
Message-ID: <42EC21F8.3040704@gmail.com>

Phillip J. Eby wrote:
> I like this a lot, and a good bit of it could actually be done in 2.5, 
> apart from the Exception/StandardError move, assuming also that the 
> renamed errors were also available under their old names.  We could 
> probably go so far as to add Raisable to the hierarchy, but I don't 
> think we could actually get quite to your proposed structure without 
> breaking any programs.  On the other hand, if we introduce 
> CriticalException and ControlFlowException in 2.5 (inheriting from 
> Exception), and create a new Error base for StandardError, then promote 
> subclassing and catching it instead of Exception, then there will be 
> less to do in 3.0.  So, my thoughts for the 2.x series are:
> 
> 
>    Exception
>       CriticalException
>       ControlFlowException
>       Error
>          StandardError

If we leave Exception at the top of the hierarchy for Py3k, and use Error to 
replace StandardError, the hierarchy could look like this:

  Exception
  +-- ControlFlowException (new)
       +-- GeneratorExit
       +-- KeyboardInterrupt
       +-- StopIteration
       +-- SystemExit
  +-- CriticalError (new)
       +-- MemoryError
       +-- SystemError
  +-- Error (formerly StandardError)
       +-- AssertionError
       +-- AttributeError
       +-- ImportError
       +-- TypeError
       +-- WeakReferenceError (formerly ReferenceError)

I wouldn't mind using Exception/Error instead of Raisable/Exception - and it 
seriously reduces the pain of making this transition. Indeed, most of it 
becomes doable within the 2.x series - the only tricky parts are semantic 
changes involved with moving the KeyboardInterrupt, MemoryError and 
SystemError out from under StandardError, and moving EOFError under IOError.

So the question is whether or not the Raisable/Exception combination is liked 
enough that we want to dance through the requisite hoops to get there.

Notice that I've classified KeyboardInterrupt as user-initiated control flow 
and put it under ControlFlowException above. This means that everything under 
CriticalError and Error actually ends with the word 'Error'.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From bcannon at gmail.com  Sun Jul 31 04:03:15 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 19:03:15 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <20050730161526.77C1.JCARLSON@uci.edu>
References: <42EB8402.10902@gmail.com>
	<bbaeab1005073015595854ec8a@mail.gmail.com>
	<20050730161526.77C1.JCARLSON@uci.edu>
Message-ID: <bbaeab10050730190351d4d4c2@mail.gmail.com>

On 7/30/05, Josiah Carlson <jcarlson at uci.edu> wrote:
> 
> Brett Cannon <bcannon at gmail.com> wrote:
> 
> > > +-- Warning
> > >      +-- DeprecationWarning
> > >      +-- FutureWarning
> > >      +-- PendingDeprecationWarning
> >
> > Don't like the idea of having DeprecationWarning inherit from
> > PendingDeprecationWarning?
> 
> Not all DeprecationWarnings are Pending, but all
> PendingDeprecationWarnings are DeprecationWarnings.
> 

See, I don't agree with that logic.  DeprecationWarning means
something has been deprecated, while PendingDeprecationWarning means
something will be deprecated in the future.  I am say that the for
DeprecationWarning, the future is now and thus is a
PendingDeprecationWarning as well.

It also just makes sense from the standpoint of catching warnings.  If
you care about catching PendingDeprecationWarning you are going to
care about catching a DeprecationWarning since if you are worrying
about the less severe version you are definitely going to care about
the most severe case.

-Brett

From bcannon at gmail.com  Sun Jul 31 04:15:24 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 19:15:24 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EC1BED.2010502@gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com> <42EB8402.10902@gmail.com>
	<bbaeab1005073015595854ec8a@mail.gmail.com>
	<42EC1BED.2010502@gmail.com>
Message-ID: <bbaeab1005073019152768845c@mail.gmail.com>

On 7/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
> > Nick, are you going go start subbing in for Tim when he is busy and
> > take my work that I spent hours on, come up with an alternative that
> > took 10 minutes, and have everyone end up loving your newfangled idea
> > 10x more than my original?  =)
> 
> It's like editing creative writing - I find it far, far easier to take
> something good and tweak it to make it better, than to come up with something
> good in the first place ;)
>

You stand on the shoulder of a giant (and I am only partially kidding;
people who have met me will get the joke)!
 
> >>+-- Exception (formerly StandardError)
> >>     +-- AssertionError
> >>     +-- AttributeError
> >
> >
> > I am still up for moving AttributeError, but with the amount of
> > arguing going on between where it should go I am not going to be
> > shocked if we go with the status quo.
> 
> Exactly my thought. I had it under "NameError" for a while, but had difficulty
> coming up with a case where lumping it in with the lexical scoping errors was
> actually beneficial.
> 
> Eventually, the fact that it is easy to add another exception to an except
> clause, but hard to remove a child you don't want that inherits from a parent
> you do want persauded me to leave this one alone.
> 

I think this one will require BDFL pronouncement to be moved since
this already looks like a contested idea.  And I don't think Guido is
going to care enough to want to see it moved.

> >>     +-- EnvironmentError
> >>         +-- OSError
> >>             +-- WindowsError (possibly remove this from builtins)
> >
> >
> > If we are going to lack exceptions for other OSs, I say remove it.  No
> > reason Windows should get special treatment with a built-in exception.
> 
> True. And the interface looks the same as the normal OSError interface, so it
> should be possible to replace all uses with a basic OSError.
> 

Glad you agree.  =)

> >>     +-- NameError
> >>         +-- UnboundLocalError
> >
> >
> > What about UnboundGlobalError?
> 
> I realised this was a misnomer. A failed name lookup actually means:
>    - the name was not in locals
>    - the name was not in any lexically containing scope
>    - the name was not in the module globals
>    - the name was not in builtins
> 
> The program doesn't know which of those namespaces was *meant* to contain the
> name - it only knows that none of them actually contained it. This criticism
> also applies to the current wording of the NameError text used in this
> situation (which implies the name should have been in the module globals).
> 
> Now, a case could possibly be made for separate errors for cases like the
> following:
> 
>    def f():
>      global x
>      print x # UnboundGlobalError (currently NameError, with usual text)
> 
>    def f():
>      def g():
>        print x
>      g() # UnboundFreeVariableError (currently NameError, with specific text)
>      x = 1
> 
> Like UnboundLocalError, in both of these cases, the name is potentially known
> to the compiler - it simply hasn't been bound to anything yet.
> 

That was what I was thinking as the use case for UnboundGlobalError. 
Also, if you read the docs on NameError, it explicitly states that it
is for global names that are not found.

I am willing to toss in an exception for the failure to find a free
variable (although I would call it UnboundFreeError) to flesh this
namespace hierarchy out.

Then again you could argue you should inherit from each other since a
missing local is kind of lack missing the global namespace as well,
but that kind of purity just doesn't work for me in this case.

[rest of my response to this email is forthcoming]

-Brett

From bcannon at gmail.com  Sun Jul 31 04:20:20 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 19:20:20 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EC1BED.2010502@gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com> <42EB8402.10902@gmail.com>
	<bbaeab1005073015595854ec8a@mail.gmail.com>
	<42EC1BED.2010502@gmail.com>
Message-ID: <bbaeab10050730192084b290f@mail.gmail.com>

On 7/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
[SNIP]
> >>     +-- RuntimeError
> > I still don't like the name.
> 
> I'm not that fond of it either - but as the builtin exception most likely to
> be used (abused?) by user code, I expect changing its name would be more pain
> than it's worth.
>

Maybe, but I am still going to nudge for a change.  It might get shot
down in the end, but at least I can say I tried.
 
> >>         +-- NotImplementedError
> > Interesting idea, but I don't view them as the same.  Everyone uses
> > RuntimeError as a Poor Man's Exception, not as an actual runtime
> > error.
> 
> This particular inheritance is copied from Python 2.4 :)
> 

Ah, oops.  =)

Well, I still don't think they should inherit like that and instead be
decoupled.

> I find the main trick with making RuntimeError more palatable is to avoid
> thinking of 'runtime' in the sense of 'Python runtime', as in 'Python VM'.
> That's not what this error is about - a Python VM error is a SystemError.
> Instead, a RuntimeError is a generic application error - something which
> happened during happened at program runtime.
> 

Right, you shouldn't think that, but isn't that what you thought
initially?  That is why I want to rename RuntimeError.

> Renaming RuntimeWarning to SemanticsWarning should help with that distinction.
> 

Well, not once the name is changed since people won't know about the
former name connection.  =)

> >>+-- Warning
> >>     +-- DeprecationWarning
> >>     +-- FutureWarning
> >>     +-- PendingDeprecationWarning
> >
> >
> > Don't like the idea of having DeprecationWarning inherit from
> > PendingDeprecationWarning?
> 
> Not really. Mainly because I'm not sure which way the inheritance should go -
> I could understand someone wanting to suppress PendingDeprecationWarnings
> without suppressing DeprecationWarnings. On the other hand, there's your
> argument that a 'DeprecationWarning is just a PendingDeprecationWarning with a
> shorter timeframe'.
> 
> Again, I fell back on the concept that Python's except clause makes it easy to
> ask for both if you want both, but makes it relatively difficult to undo
> exception inheritance if it isn't what you want.
> 

True, but the hierarchy should still properly reflect increasing
severity in my opinion.  I am going to push for this; we will see if I
get pushed back enough to not do it.

-Brett

From bcannon at gmail.com  Sun Jul 31 04:23:39 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 30 Jul 2005 19:23:39 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EC21F8.3040704@gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>
	<42EC21F8.3040704@gmail.com>
Message-ID: <bbaeab100507301923742b7b60@mail.gmail.com>

On 7/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Phillip J. Eby wrote:
> > I like this a lot, and a good bit of it could actually be done in 2.5,
> > apart from the Exception/StandardError move, assuming also that the
> > renamed errors were also available under their old names.  We could
> > probably go so far as to add Raisable to the hierarchy, but I don't
> > think we could actually get quite to your proposed structure without
> > breaking any programs.  On the other hand, if we introduce
> > CriticalException and ControlFlowException in 2.5 (inheriting from
> > Exception), and create a new Error base for StandardError, then promote
> > subclassing and catching it instead of Exception, then there will be
> > less to do in 3.0.  So, my thoughts for the 2.x series are:
> >
> >
> >    Exception
> >       CriticalException
> >       ControlFlowException
> >       Error
> >          StandardError
> 
> If we leave Exception at the top of the hierarchy for Py3k, and use Error to
> replace StandardError, the hierarchy could look like this:
> 
>   Exception
>   +-- ControlFlowException (new)
>        +-- GeneratorExit
>        +-- KeyboardInterrupt
>        +-- StopIteration
>        +-- SystemExit
>   +-- CriticalError (new)
>        +-- MemoryError
>        +-- SystemError
>   +-- Error (formerly StandardError)
>        +-- AssertionError
>        +-- AttributeError
>        +-- ImportError
>        +-- TypeError
>        +-- WeakReferenceError (formerly ReferenceError)
> 
> I wouldn't mind using Exception/Error instead of Raisable/Exception - and it
> seriously reduces the pain of making this transition. Indeed, most of it
> becomes doable within the 2.x series - the only tricky parts are semantic
> changes involved with moving the KeyboardInterrupt, MemoryError and
> SystemError out from under StandardError, and moving EOFError under IOError.
> 

I can live with this, but that will require Guido's stamp of approval.

> So the question is whether or not the Raisable/Exception combination is liked
> enough that we want to dance through the requisite hoops to get there.
> 
> Notice that I've classified KeyboardInterrupt as user-initiated control flow
> and put it under ControlFlowException above. This means that everything under
> CriticalError and Error actually ends with the word 'Error'.
> 

I don't know if I like this change in inheritance.  While we do tend
to use KeyboardInterrupt as a way to kill a program, is that really
control flow, or a critical exception that the program needs to stop
because an serious event occurred?

I prefer the latter explanation.

-Brett

From jcarlson at uci.edu  Sun Jul 31 04:25:06 2005
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sat, 30 Jul 2005 19:25:06 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab10050730190351d4d4c2@mail.gmail.com>
References: <20050730161526.77C1.JCARLSON@uci.edu>
	<bbaeab10050730190351d4d4c2@mail.gmail.com>
Message-ID: <20050730191709.77C4.JCARLSON@uci.edu>


Brett Cannon <bcannon at gmail.com> wrote:
> 
> On 7/30/05, Josiah Carlson <jcarlson at uci.edu> wrote:
> > 
> > Brett Cannon <bcannon at gmail.com> wrote:
> > 
> > > > +-- Warning
> > > >      +-- DeprecationWarning
> > > >      +-- FutureWarning
> > > >      +-- PendingDeprecationWarning
> > >
> > > Don't like the idea of having DeprecationWarning inherit from
> > > PendingDeprecationWarning?
> > 
> > Not all DeprecationWarnings are Pending, but all
> > PendingDeprecationWarnings are DeprecationWarnings.
> > 
> 
> See, I don't agree with that logic.  DeprecationWarning means
> something has been deprecated, while PendingDeprecationWarning means
> something will be deprecated in the future.  I am say that the for
> DeprecationWarning, the future is now and thus is a
> PendingDeprecationWarning as well.
> 
> It also just makes sense from the standpoint of catching warnings.  If
> you care about catching PendingDeprecationWarning you are going to
> care about catching a DeprecationWarning since if you are worrying
> about the less severe version you are definitely going to care about
> the most severe case.

Well, I would also disagree with your logic.  I would mask the pending
deprecations because they are still pending, but when they are actually
deprecated, I would like to know about it, hence wouldn't mask it.  By
having DeprecationWarning inherit from PendingDeprecationWarning as you
suggest, I would not have the ability to do so, and neither would anyone
else.

Because there are two different ways of seeing it, and neither of us is
likely to convince the other, perhaps it is better for the fate of of
this conversation that they aren't inheriting from one or the other, and
people can be explicit about what kinds of deprecations they want to
mask.

 - Josiah


From aahz at pythoncraft.com  Sun Jul 31 06:11:29 2005
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 30 Jul 2005 21:11:29 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab100507301217532e0b85@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
	<bbaeab100507301217532e0b85@mail.gmail.com>
Message-ID: <20050731041128.GA10535@panix.com>

On Sat, Jul 30, 2005, Brett Cannon wrote:
>
> My view of Python 3.0 was that backwards-compatibility would not be a
> gimme in anyway.  I personally am willing to break stuff in the name
> of clarity, which is the point of this whole endeavour.  While I am
> willing to back off on some the proposed changes, I do think the basic
> spirit of it is correct.

My take is that for Python 3.0, backwards compatibility is no longer a
critical priority -- but any breakage still needs to be argued for and
balanced.  We want to avoid unnecessary breakage.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.

From fdrake at acm.org  Sun Jul 31 08:27:28 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sun, 31 Jul 2005 02:27:28 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab10050730192084b290f@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EC1BED.2010502@gmail.com>
	<bbaeab10050730192084b290f@mail.gmail.com>
Message-ID: <200507310227.28328.fdrake@acm.org>

On Saturday 30 July 2005 22:20, Brett Cannon wrote:
 > True, but the hierarchy should still properly reflect increasing
 > severity in my opinion.  I am going to push for this; we will see if I
 > get pushed back enough to not do it.

I have no idea what you mean by "properly reflect increasing severity".  
Should the more severe or less severe case be derived from the other?  I 
doubt there is a single answer that we can readily agree on.

If DeprecationWarning and PendingDeprecationWarning need a class-hierarchy 
relationship (and I think they do; it *is* reasonable for someone to deal 
with them generically if they can reasonably want to deal with either), then 
it seems they need a common base:

  +--AnyDeprecationWarning
     +--DeprecationWarning
     +--PendingDeprecationWarning


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From ncoghlan at gmail.com  Sun Jul 31 09:05:24 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 31 Jul 2005 17:05:24 +1000
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab100507301923742b7b60@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>	
	<42EB576F.3060309@egenix.com>	
	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>	
	<42EC21F8.3040704@gmail.com>
	<bbaeab100507301923742b7b60@mail.gmail.com>
Message-ID: <42EC7834.5030605@gmail.com>

Brett Cannon wrote:
>>Notice that I've classified KeyboardInterrupt as user-initiated control flow
>>and put it under ControlFlowException above. This means that everything under
>>CriticalError and Error actually ends with the word 'Error'.
> 
> I don't know if I like this change in inheritance.  While we do tend
> to use KeyboardInterrupt as a way to kill a program, is that really
> control flow, or a critical exception that the program needs to stop
> because an serious event occurred?
> 
> I prefer the latter explanation.

You're probably right. How does the following reasoning sound:

SystemExit, GeneratorExit and StopIteration are all deliberately triggered by 
certain well-defined elements of normal application code. That is, only 
certain operations will ever result in a ControlFlowException being raised.

KeyboardInterrupt is a better fit with MemoryError and SystemError - something 
that occurs unexpectedly, at an arbitary point during program execution. That 
is, a CriticalError may be raised when attempting to execute almost any operation.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From metawilm at gmail.com  Sun Jul 31 12:36:47 2005
From: metawilm at gmail.com (Willem Broekema)
Date: Sun, 31 Jul 2005 12:36:47 +0200
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab100507301923742b7b60@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>
	<42EC21F8.3040704@gmail.com>
	<bbaeab100507301923742b7b60@mail.gmail.com>
Message-ID: <f6bc9b4905073103367c19832@mail.gmail.com>

On 7/31/05, Brett Cannon <bcannon at gmail.com> wrote:
> While we do tend to use KeyboardInterrupt as a way to kill a
> program, is that really control flow, or a critical exception
> that the program needs to stop because an serious event
> occurred?

I does not seem right to me to think of KeyboardInterrupt as a means
to cause program halting. An interpreter could in principle recover
from it and resume execution of the program.

The behaviour of the current Python interpreters is that upon
encountering an uncaught KeyboardInterrupt (as with any uncaught
exception), computation is aborted and a backtrace printed. But that
is not how it /must be/ as there might be alternative interpreters
that upon encountering an uncaught KeyboardInterrupt will pause
execution of the program, but then allow the user to either continue
or abort execution, effectively not stopping but pausing the program.

Because of this possible recovery, thinking of KeyboardInterrupt as
"in order to abort the program, the user has caused a keyboard
interrupt" is wrong; it should be more like just "the user has
interrupted the computation" and whether or not the program is
consequently aborted is not predefined.

- Willem

From ncoghlan at gmail.com  Sun Jul 31 13:25:59 2005
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 31 Jul 2005 21:25:59 +1000
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <f6bc9b4905073103367c19832@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>	<42EB576F.3060309@egenix.com>	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>	<42EC21F8.3040704@gmail.com>	<bbaeab100507301923742b7b60@mail.gmail.com>
	<f6bc9b4905073103367c19832@mail.gmail.com>
Message-ID: <42ECB547.40604@gmail.com>

Willem Broekema wrote:
> On 7/31/05, Brett Cannon <bcannon at gmail.com> wrote:
> 
>>While we do tend to use KeyboardInterrupt as a way to kill a
>>program, is that really control flow, or a critical exception
>>that the program needs to stop because an serious event
>>occurred?
> 
> 
> I does not seem right to me to think of KeyboardInterrupt as a means
> to cause program halting. An interpreter could in principle recover
> from it and resume execution of the program.

Actually, even in some such theoretical "Did you really mean that?" 
interpreter, the KeyboardInterrupt only gets raised if the interpreter 
determines that yes, the user really did want the program terminated. 
Otherwise, no exception is raised at all, and execution continues as usual.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com

From fdrake at acm.org  Sun Jul 31 16:41:47 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sun, 31 Jul 2005 10:41:47 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <f6bc9b4905073103367c19832@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<bbaeab100507301923742b7b60@mail.gmail.com>
	<f6bc9b4905073103367c19832@mail.gmail.com>
Message-ID: <200507311041.47846.fdrake@acm.org>

On Sunday 31 July 2005 06:36, Willem Broekema wrote:
 > I does not seem right to me to think of KeyboardInterrupt as a means
 > to cause program halting. An interpreter could in principle recover
 > from it and resume execution of the program.

Somewhat.  An interrupt may well not mean that the program should terminate, 
but may simply mean that the current operation should be stopped (as in many 
sorts of command interpreters).  It's still *reasonable* to exit the Python 
interpreter if the application doesn't handle it; I can't think of any other 
reasonable default interpretation.  (The interactive interpreter is simply an 
application that does handle the interrupt in an application-specific way.)

So I think its reasonable to consider it a critical exception, because it's 
not predictable the way the control flow exceptions are; it's user-generated 
instead of application-generated.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From foom at fuhm.net  Sun Jul 31 18:12:06 2005
From: foom at fuhm.net (James Y Knight)
Date: Sun, 31 Jul 2005 12:12:06 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python  3.0
In-Reply-To: <42EC21F8.3040704@gmail.com>
References: <42EB576F.3060309@egenix.com>
	<bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>
	<42EC21F8.3040704@gmail.com>
Message-ID: <E062D4B9-3130-4468-B1B3-148B3708BBE0@fuhm.net>

On Jul 30, 2005, at 8:57 PM, Nick Coghlan wrote:
> I wouldn't mind using Exception/Error instead of Raisable/Exception  
> - and it
> seriously reduces the pain of making this transition. Indeed, most  
> of it
> becomes doable within the 2.x series - the only tricky parts are  
> semantic
> changes involved with moving the KeyboardInterrupt, MemoryError and
> SystemError out from under StandardError, and moving EOFError under  
> IOError.

It seems to me that it *increases* the pain of transition.
I do not see any reason why adding a new class above the current  
hierarchy causes any problems. However, changing the recommended base  
class for user-defined exceptions from "Exception" to "Error" will  
cause problems for *every* library.

Moving KeyboardInterrupt, MemoryError, and SystemError out from under  
Exception will be a backwards compatibility issue, but that's the  
case in all proposals. Additionally, I predict the pain from doing  
that will be minor. In cases where apps want to catch *all*  
exceptions, they must already use "except:" instead of "except  
Exception:", as not all exceptions derive from Exception. And  
catching the above three in any circumstance other than when  
explicitly mentioned and when wanting to catch every exception is  
probably wrong. So moving them will probably not cause many programs  
to malfunction.

I think the following could be done in Py2.5:
a) add Raisable above Exception
b) move KeyboardInterrupt, MemoryError, and SystemError somewhere  
under Raisable but not under Exception
c) pending deprecation warning for "except:" and raising objects that  
aren't subclasses of "Raisable".
d) (not really related, but while I'm at it...) Allow exceptions  
derived from object (with Raisable too, of course)

For Py2.6:
a) change pending deprecation warning above to deprecation warning.

James

From bcannon at gmail.com  Sun Jul 31 18:15:15 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sun, 31 Jul 2005 09:15:15 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <200507310227.28328.fdrake@acm.org>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EC1BED.2010502@gmail.com>
	<bbaeab10050730192084b290f@mail.gmail.com>
	<200507310227.28328.fdrake@acm.org>
Message-ID: <bbaeab100507310915290304a9@mail.gmail.com>

On 7/30/05, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
> On Saturday 30 July 2005 22:20, Brett Cannon wrote:
>  > True, but the hierarchy should still properly reflect increasing
>  > severity in my opinion.  I am going to push for this; we will see if I
>  > get pushed back enough to not do it.
> 
> I have no idea what you mean by "properly reflect increasing severity".
> Should the more severe or less severe case be derived from the other?  I
> doubt there is a single answer that we can readily agree on.
> 
> If DeprecationWarning and PendingDeprecationWarning need a class-hierarchy
> relationship (and I think they do; it *is* reasonable for someone to deal
> with them generically if they can reasonably want to deal with either), then
> it seems they need a common base:
> 
>   +--AnyDeprecationWarning
>      +--DeprecationWarning
>      +--PendingDeprecationWarning
> 

I can compromise and go with a common base class that both directly
inherit from.

-Brett

From pje at telecommunity.com  Sun Jul 31 18:15:54 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 31 Jul 2005 12:15:54 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python  3.0
In-Reply-To: <42EC7834.5030605@gmail.com>
References: <bbaeab100507301923742b7b60@mail.gmail.com>
	<bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>
	<42EC21F8.3040704@gmail.com>
	<bbaeab100507301923742b7b60@mail.gmail.com>
Message-ID: <5.1.1.6.0.20050731121235.02713de8@mail.telecommunity.com>

At 05:05 PM 7/31/2005 +1000, Nick Coghlan wrote:
>Brett Cannon wrote:
> >>Notice that I've classified KeyboardInterrupt as user-initiated control 
> flow
> >>and put it under ControlFlowException above. This means that everything 
> under
> >>CriticalError and Error actually ends with the word 'Error'.
> >
> > I don't know if I like this change in inheritance.  While we do tend
> > to use KeyboardInterrupt as a way to kill a program, is that really
> > control flow, or a critical exception that the program needs to stop
> > because an serious event occurred?
> >
> > I prefer the latter explanation.
>
>You're probably right. How does the following reasoning sound:
>
>SystemExit, GeneratorExit and StopIteration are all deliberately triggered by
>certain well-defined elements of normal application code. That is, only
>certain operations will ever result in a ControlFlowException being raised.
>
>KeyboardInterrupt is a better fit with MemoryError and SystemError - 
>something
>that occurs unexpectedly, at an arbitary point during program execution. That
>is, a CriticalError may be raised when attempting to execute almost any 
>operation.

Ugh.  A KeyboardInterrupt isn't an error, let alone a critical one.  The 
fact that it occurs unexpectedly has nothing to do with it.  A 
CriticalError needs different treatment than a KeyboardInterrupt for things 
like logging, notifications, etc.  Heck, it needs different treatment just 
because a KeyboardInterrupt is something you can sanely recover from and 
gracefully shut down with.  The odds of you recovering from an actual 
CriticalError are negligible.

It's not the same thing, no matter what explanation you prefer.  ;)


From bcannon at gmail.com  Sun Jul 31 18:17:10 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sun, 31 Jul 2005 09:17:10 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <42EC7834.5030605@gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>
	<42EC21F8.3040704@gmail.com>
	<bbaeab100507301923742b7b60@mail.gmail.com>
	<42EC7834.5030605@gmail.com>
Message-ID: <bbaeab100507310917fddda1e@mail.gmail.com>

On 7/31/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
> >>Notice that I've classified KeyboardInterrupt as user-initiated control flow
> >>and put it under ControlFlowException above. This means that everything under
> >>CriticalError and Error actually ends with the word 'Error'.
> >
> > I don't know if I like this change in inheritance.  While we do tend
> > to use KeyboardInterrupt as a way to kill a program, is that really
> > control flow, or a critical exception that the program needs to stop
> > because an serious event occurred?
> >
> > I prefer the latter explanation.
> 
> You're probably right. How does the following reasoning sound:
> 
> SystemExit, GeneratorExit and StopIteration are all deliberately triggered by
> certain well-defined elements of normal application code. That is, only
> certain operations will ever result in a ControlFlowException being raised.
> 
> KeyboardInterrupt is a better fit with MemoryError and SystemError - something
> that occurs unexpectedly, at an arbitary point during program execution. That
> is, a CriticalError may be raised when attempting to execute almost any operation.
> 

Yeah, those explanations work for me.  I think I am going to have to
write an explanation for every exception so its usage is clear.

-Brett

From bcannon at gmail.com  Sun Jul 31 18:21:45 2005
From: bcannon at gmail.com (Brett Cannon)
Date: Sun, 31 Jul 2005 09:21:45 -0700
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <f6bc9b4905073103367c19832@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>
	<42EC21F8.3040704@gmail.com>
	<bbaeab100507301923742b7b60@mail.gmail.com>
	<f6bc9b4905073103367c19832@mail.gmail.com>
Message-ID: <bbaeab1005073109217f3a33f1@mail.gmail.com>

On 7/31/05, Willem Broekema <metawilm at gmail.com> wrote:
> On 7/31/05, Brett Cannon <bcannon at gmail.com> wrote:
> > While we do tend to use KeyboardInterrupt as a way to kill a
> > program, is that really control flow, or a critical exception
> > that the program needs to stop because an serious event
> > occurred?
> 
> I does not seem right to me to think of KeyboardInterrupt as a means
> to cause program halting. An interpreter could in principle recover
> from it and resume execution of the program.
> 

Same goes for MemoryError as well, but you probably don't want to
catch that exception either.

> The behaviour of the current Python interpreters is that upon
> encountering an uncaught KeyboardInterrupt (as with any uncaught
> exception), computation is aborted and a backtrace printed. But that
> is not how it /must be/ as there might be alternative interpreters
> that upon encountering an uncaught KeyboardInterrupt will pause
> execution of the program, but then allow the user to either continue
> or abort execution, effectively not stopping but pausing the program.
> 
> Because of this possible recovery, thinking of KeyboardInterrupt as
> "in order to abort the program, the user has caused a keyboard
> interrupt" is wrong; it should be more like just "the user has
> interrupted the computation" and whether or not the program is
> consequently aborted is not predefined.
> 

But interpreter termination is not guaranteed for any exception, even
SystemError since it can be caught and not re-raised.  Plus the common
use of hittting ctrl-c while an app is running is to kill it, not to
pause the execution.

But it doesn't sound like you are arguing against putting
KeyboardInterrupt under CriticalException, but just the explanation I
gave, right?

-Brett

From fdrake at acm.org  Sun Jul 31 18:26:44 2005
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sun, 31 Jul 2005 12:26:44 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <bbaeab100507310917fddda1e@mail.gmail.com>
References: <bbaeab100507291734337930a2@mail.gmail.com>
	<42EC7834.5030605@gmail.com>
	<bbaeab100507310917fddda1e@mail.gmail.com>
Message-ID: <200507311226.44696.fdrake@acm.org>

On Sunday 31 July 2005 12:17, Brett Cannon wrote:
 > Yeah, those explanations work for me.  I think I am going to have to
 > write an explanation for every exception so its usage is clear.

That said, I agree with Phillip; a KeyboardInterrupt isn't an error, it's 
asynchronous user input.  That makes it a child of Raisable, not Error.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From pje at telecommunity.com  Sun Jul 31 18:49:32 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 31 Jul 2005 12:49:32 -0400
Subject: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
In-Reply-To: <E062D4B9-3130-4468-B1B3-148B3708BBE0@fuhm.net>
References: <42EC21F8.3040704@gmail.com> <42EB576F.3060309@egenix.com>
	<bbaeab100507291734337930a2@mail.gmail.com>
	<42EB576F.3060309@egenix.com>
	<5.1.1.6.0.20050730145112.027146e8@mail.telecommunity.com>
	<42EC21F8.3040704@gmail.com>
Message-ID: <5.1.1.6.0.20050731124043.027e3768@mail.telecommunity.com>

At 12:12 PM 7/31/2005 -0400, James Y Knight wrote:
>On Jul 30, 2005, at 8:57 PM, Nick Coghlan wrote:
> > I wouldn't mind using Exception/Error instead of Raisable/Exception
> > - and it
> > seriously reduces the pain of making this transition. Indeed, most
> > of it
> > becomes doable within the 2.x series - the only tricky parts are
> > semantic
> > changes involved with moving the KeyboardInterrupt, MemoryError and
> > SystemError out from under StandardError, and moving EOFError under
> > IOError.
>
>It seems to me that it *increases* the pain of transition.
>I do not see any reason why adding a new class above the current
>hierarchy causes any problems. However, changing the recommended base
>class for user-defined exceptions from "Exception" to "Error" will
>cause problems for *every* library.

I think you're ignoring the part where most exception handlers are already 
broken.  At least adding CriticalException and ControlFlowException makes 
it possible to add this:

     try:
         ...
     except (CriticalException,ControlFlowException):
         raise
     except:
         ...

This isn't great, I admit, but at least it would actually *work*.

I also don't see how changing the recommended base class from Exception to 
Error causes *problems* for every library.  Sure, it forces them to move 
(eventually!), but it's a trivial change, and makes it *possible* to do the 
right thing with exceptions (e.g. except Error:) as soon as all the 
libraries you depend on have moved to using Error.


>Moving KeyboardInterrupt, MemoryError, and SystemError out from under
>Exception will be a backwards compatibility issue, but that's the
>case in all proposals.

Actually, in my tweak of Nick's proposal they're still Exception 
subclasses, so nothing breaks.


>Additionally, I predict the pain from doing
>that will be minor. In cases where apps want to catch *all*
>exceptions, they must already use "except:" instead of "except
>Exception:", as not all exceptions derive from Exception. And
>catching the above three in any circumstance other than when
>explicitly mentioned and when wanting to catch every exception is
>probably wrong. So moving them will probably not cause many programs
>to malfunction.

In which case, maybe we should just implement Nick's full proposal, since 
the only thing that it would break is code that uses "except Exception:" to 
catch SystemExit or StopIteration.


From falcon at intercable.ru  Sun Jul 31 19:45:26 2005
From: falcon at intercable.ru (falcon)
Date: Sun, 31 Jul 2005 21:45:26 +0400
Subject: [Python-Dev] __autoinit__ (Was: Proposal: reducing self.x=x;
	self.y=y; self.z=z boilerplate code)
Message-ID: <139701967.20050731214526@intercable.ru>

Hello python-list,

As I Understood, semantic may be next:

def qwerty(a,a.i,b,b.i,f.j):
        pass

Would work like:
  
def qwerty(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5):
        (a,a.i,b,b.i,f.j)=(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5)
        del anonymous1
        del anonymous2
        del anonymous3
        del anonymous4
        del anonymous5

If so then I like it, because it more explicit than anything other
and it is working right now. I just tryed:

>>> class Stub:
...     pass
>>> def qwer(a1,a2,a3,a4,a5):
...     (a,a.i,b,b.i,f['i'])=(a1,a2,a3,a4,a5)
...     del a1
...     del a2
...     del a3
...     del a4
...     del a5
...     print (a,a.i,b,b.i,f['i'])
>>> f={}
>>> qwer(Stub(),1,Stub(),2,3)
(<__main__.Stub instance at 0x00C49530>, 1, <__main__.Stub instance at 0x00C498C8>, 2, 3)

So there are not too much for implement.
Another question - named arguments. How I can assign to them?
May be so:
f={}
def qwerty(a,a.i,f['i']):
    print (a,a.i,f['i'])
qwerty(f['i']=3,a=Stub(),a.i=4) - ?

and for __init__:
class MyClass:
    def __init__(self,self.i,self.j,self.k):
        pass

MyObject = MyClass(self.i=1,self.j=2,self.k=3)

?

or may be there can be an aliase syntax?

class MyClass:
    def __init__(self, self.i by i,self.j by j, self.k by k):
        pass

MyObject = MyClass(i=1,j=2,k=3)

--
Sokolov Yura
falcon at intercable.ru