From tim.one@comcast.net  Sun Jun  1 06:11:57 2003
From: tim.one@comcast.net (Tim Peters)
Date: Sun, 01 Jun 2003 01:11:57 -0400
Subject: [Python-Dev] more-precise instructions for "Python.h first"?
In-Reply-To: <ullwmkbra.fsf@boost-consulting.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEHHEIAB.tim.one@comcast.net>

[David Abrahams]
> ...
> I can't make sure that my users can't run into problems without
> understanding everything about Python and Posix which causes the rule
> to exist in the first place (and I don't), and continuously monitoring
> Python into the future to make sure that the distribution of Posix
> configuration information across its headers doesn't change in a way
> that invalidates previous assumptions.

Well, we're in the same boat:  we can't ensure that Python users can't run
into problems without knowing everything about how the union of all flaky
platform headers (not just POSIX) will work for all time either.  We do know
that, historically, we've been able to hack around all problems that have
arisen by sticking Python.h first.  There's no guarantee that will always
work, though.

> The current rule doesn't work for me,

It doesn't work for us either, at least not on principle.  It just happens
to have "been enough" in practice so far.

> but I'd like to be following _some_ sanctioned rule to reduce the
> chance of problems today and in the future. I'm making an educated
> guess that the rule is much more-sweeping than Python development
> needs it to be.  Isn't there some Python internal configuration header
> which can be #included first and which will accomplish all the same
> things as far as system-header inclusion order is concerned?

Sorry, I don't know.  I do know that changes to the headers are usually
followed by problems on some handful of systems that can't be predicted in
advance.  I'll note that life is much easier if you drop support for all
systems other than Win32 <wink>.




From tim.one@comcast.net  Sun Jun  1 06:32:36 2003
From: tim.one@comcast.net (Tim Peters)
Date: Sun, 01 Jun 2003 01:32:36 -0400
Subject: [Python-Dev] Algoritmic Complexity Attack on Python
In-Reply-To: <200305310041.h4V0fsF20796@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEHJEIAB.tim.one@comcast.net>

[Gudio]
> Of course, such programs are already vulnerable to changes in the hash
> implementation between Python versions (which has happened before).

Last Thursday, Jim and I speculated about adding a persistent set type to
Zope, implemented via an IOBTree under the covers, mapping int hash codes to
lists of elements.  I'm sure someone else has already done something "like
that"; I know I have in the past, but only to run monstrously large
hash-function evaluation tests, where I needed to accumulate results across
multiple runs.

It's curious that persistence schemes are fragile in areas Python doesn't
really care about, like how objects of different types compare to each
other, how class instances that don't define __cmp__ compare to each other,
and in exactly which bit pattern hash(whatever) returns.  In Python 3 it may
be nice to define the results of such things more carefully in platform- and
release-independent ways -- or maybe to raise exceptions instead of making
results up, forcing users to confront the issues explicitly.  Lots of
tradeoffs here ...



From martin@v.loewis.de  Sun Jun  1 08:38:28 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 01 Jun 2003 09:38:28 +0200
Subject: [Python-Dev] more-precise instructions for "Python.h first"?
In-Reply-To: <ullwmkbra.fsf@boost-consulting.com>
References: <uvfvrrxow.fsf@boost-consulting.com>
 <m34r3baxna.fsf@mira.informatik.hu-berlin.de>
 <ullwmkbra.fsf@boost-consulting.com>
Message-ID: <m3brxijlhn.fsf@mira.informatik.hu-berlin.de>

David Abrahams <dave@boost-consulting.com> writes:

> The current rule doesn't work for me, but I'd like to be following
> _some_ sanctioned rule to reduce the chance of problems today and in
> the future. I'm making an educated guess that the rule is much
> more-sweeping than Python development needs it to be.  Isn't there
> some Python internal configuration header which can be #included first
> and which will accomplish all the same things as far as system-header
> inclusion order is concerned?

I can't think of a less strict rule that is still comprehensible. I
did not comprehend the wording that you first proposed, since it
referred to preconditions that are fuzzy (what is xxxx.h?)

If you come up with a wording of a less strict rule, I can try to
guess whether that rule would also work, on the systems I care about.
In drafting such wording, keep in mind that the primary motivation for
this rule is LFS support, where Python wants to select the 64-bit API
(aka "large file") on systems that support that. So any system header
that could potentially be affected by LFS selection can only be
included after LFS selection has been done.

Regards,
Martin



From Raymond Hettinger" <python@rcn.com  Sun Jun  1 09:32:17 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Sun, 1 Jun 2003 04:32:17 -0400
Subject: [Python-Dev] Descriptor write-up    [Draft:  Please comment]
Message-ID: <000901c32818$4fd52240$125ffea9@oemcomputer>

In the spirit of Michele Simionato's write-up on method resolution order, I've written up almost everything I know about
descriptors:
http://tinyurl.com/d63d

Key features:
* Defines a descriptor
* Shows the protocol and how it is called
* Shows a handmade descriptor
* Then covers functions, properties, static and class methods
* Gives examples of each
* Suggests when each would be useful
* Gives a pure python definition of each
* Provides exact references into C source to save efforts in hunting down details

I would like to hammer this into something really useful.  So, any and all suggestions are welcome.


Raymond Hettinger


P.S.  I've borrowed Alex Martelli's style of making precise descriptions of how the CPython works by showing pure Python
equivalents.



From martin@v.loewis.de  Sun Jun  1 10:15:17 2003
From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 01 Jun 2003 11:15:17 +0200
Subject: [Python-Dev] Descriptor write-up    [Draft:  Please comment]
In-Reply-To: <000901c32818$4fd52240$125ffea9@oemcomputer>
References: <000901c32818$4fd52240$125ffea9@oemcomputer>
Message-ID: <3ED9C425.7060101@v.loewis.de>

Raymond Hettinger wrote:
> I would like to hammer this into something really useful.  So, any and all suggestions are welcome.

To be really useful, it should be part of the standard Python 
documentation. So you should find a strategy to move this to the three 
major components (tutorial, language ref, library ref). I think some of
it should go into section 3 of the language reference, and the rest into
the library reference (although there is already documentation for 
property and classmethod - perhaps some of the builtins deserve their 
own subsections). Perhaps the tutorial should be extended to include 
examples for the "typical use cases".

Regards,
Martin



From pje@telecommunity.com  Sun Jun  1 11:32:36 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Sun, 01 Jun 2003 06:32:36 -0400
Subject: [Python-Dev] Descriptor write-up    [Draft:  Please
 comment]
In-Reply-To: <000901c32818$4fd52240$125ffea9@oemcomputer>
Message-ID: <5.1.0.14.0.20030601061239.034c3d00@mail.telecommunity.com>

At 04:32 AM 6/1/03 -0400, Raymond Hettinger wrote:
>In the spirit of Michele Simionato's write-up on method resolution order, 
>I've written up almost everything I know about
>descriptors:
>http://tinyurl.com/d63d
>
>Key features:
>* Defines a descriptor
>* Shows the protocol and how it is called
>* Shows a handmade descriptor
>* Then covers functions, properties, static and class methods
>* Gives examples of each
>* Suggests when each would be useful
>* Gives a pure python definition of each
>* Provides exact references into C source to save efforts in hunting down 
>details
>
>I would like to hammer this into something really useful.  So, any and all 
>suggestions are welcome.

It would be a good idea to add some information about "data" and "non-data" 
descriptors, and the differences of how their attribute lookup is 
processed.  I recently posted here about the "attribute lookup process" or 
something to that effect, which covered this.  Understanding data vs. 
non-data descriptors is important if you want to do pretty much anything 
with descriptors beyond what property() does.

This section:

"Alternatively, a descriptor is invoked automatically upon attribute 
access.  For example, obj.a looks up a in the dictionary of obj.  If obj 
defines the method __get__, then it is automatically invoked if obj is a 
new style class or object."

isn't accurate.  I think you meant to say that if 'a' defines __get__, then 
it's invoked.  But this isn't accurate either.  If obj.__dict__ has an 'a' 
entry, and the descriptor is a non-data descriptor, __get__ will be ignored 
and the contents of obj.__dict__ will be returned.  (One interesting effect 
of this is that you can create a non-data descriptor with a __get__ that 
performs a computation and stashes the result in the instance dictionary - 
from then on the computed value is returned.)

The Python code you have for the algorithm is also incorrect.  Here's a 
more accurate depiction of the process.  It's not a straight translation of 
PyGeneric_GetAttr, but an attempt to do as you have done, i.e. write a pure 
Python __getattribute__ with equivalent semantics.

     def __getattribute__(self, key):

         dict = object.__getattribute__(self, '__dict__')

         try:
             # Does the class have a descriptor for this attribute?
             descr = getattr(type(self),key)

         except AttributeError:
             # No, just use what's in the dictionary
             try:
                 return dict[key]
             except KeyError:
                 raise AttributeError


         if hasattr(descr,'__set__') and hasattr(descr,'__get__'):
              # It's a data descriptor, so use the get method
              return descr.__get__(self,type(self))

         # non-data descriptor, use __dict__ first, *then* __get__
         try:
             return dict[key]
         except KeyError:
             if hasattr(descr, '__get__'):
                 return descr.__get__(self, type(self))

         # not a descriptor, return it as-is
         return descr

As you can see, it's a bit more complex than your writeup implies.  :)



From mwh@python.net  Sun Jun  1 11:45:16 2003
From: mwh@python.net (Michael Hudson)
Date: Sun, 01 Jun 2003 11:45:16 +0100
Subject: [Python-Dev] Descriptor write-up    [Draft:  Please comment]
In-Reply-To: <000901c32818$4fd52240$125ffea9@oemcomputer> ("Raymond
 Hettinger"'s message of "Sun, 1 Jun 2003 04:32:17 -0400")
References: <000901c32818$4fd52240$125ffea9@oemcomputer>
Message-ID: <2mof1if54z.fsf@starship.python.net>

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

> I would like to hammer this into something really useful.  So, any
> and all suggestions are welcome.

Something about data descriptors (ones defining __set__) and method
descriptors (ones not defining __set__) and their differences would be
cool (particularly as this is something I don't quite understand!).

Cheers,
M.

-- 
  Those who have deviant punctuation desires should take care of their
  own perverted needs.                  -- Erik Naggum, comp.lang.lisp


From skip@mojam.com  Sun Jun  1 13:00:22 2003
From: skip@mojam.com (Skip Montanaro)
Date: Sun, 1 Jun 2003 07:00:22 -0500
Subject: [Python-Dev] Weekly Python Bug/Patch Summary
Message-ID: <200306011200.h51C0M006900@manatee.mojam.com>

Bug/Patch Summary
-----------------

372 open / 3676 total bugs (+1)
149 open / 2183 total patches (no change)

New Bugs
--------

super passes bad arguments to __get__ when used w/class (2003-05-25)
	http://python.org/sf/743267
test_socketserver: Fatal error: Invalid thread state (2003-05-26)
	http://python.org/sf/743692
sum() should be renamed (2003-05-26)
	http://python.org/sf/744051
ipv6 addrinfo is bad (2003-05-27)
	http://python.org/sf/744164
anydbm and whichdb again (2003-05-27)
	http://python.org/sf/744687
Python-Profiler bug: Bad call (2003-05-28)
	http://python.org/sf/744841
urllib2 doesn't handle urls without scheme (2003-05-28)
	http://python.org/sf/745097
xml.sax Contenthandler passes truncated data (2003-05-28)
	http://python.org/sf/745145
threads broke on FreeBSD current (2003-05-28)
	http://python.org/sf/745320
PACKAGE_*  in pyconfig.h (2003-05-30)
	http://python.org/sf/746012
TypeError raised when deepcopying built-in functions (2003-05-30)
	http://python.org/sf/746304
2.2.3c1 install-sh out of date (2003-05-30)
	http://python.org/sf/746366
socket.sendto(SOCK_DGRAM) very slow on OSX! (2003-05-31)
	http://python.org/sf/746895
indentation error in unixcompiler.py (2003-06-01)
	http://python.org/sf/746953

New Patches
-----------

patch for new func. string.findall (2003-01-27)
	http://python.org/sf/675864
Remove eval() from csv (2003-05-27)
	http://python.org/sf/744104
FreeBSD 4 port of python-2.2.3... (2003-05-31)
	http://python.org/sf/746801

Closed Bugs
-----------

python -S still displays 'Type "help", "cop...' (2003-01-22)
	http://python.org/sf/672614
patch for new func. string.findall (2003-01-27)
	http://python.org/sf/675864
Python does not build --with-pydebug on Tru64 with vendor cc (2003-02-25)
	http://python.org/sf/693094
string exceptions are deprecated (2003-04-10)
	http://python.org/sf/719367
test_bsddb3 fails (2003-04-25)
	http://python.org/sf/727571
Pimp needs to be able to update itself (2003-05-02)
	http://python.org/sf/731626
Package Manager needs Help menu (2003-05-02)
	http://python.org/sf/731635
bsddb.*open mode should default to 'r' rather than 'c' (2003-05-05)
	http://python.org/sf/732951
kwargs handled incorrectly (2003-05-06)
	http://python.org/sf/733667
Function for creating/extracting CoreFoundation types (2003-05-08)
	http://python.org/sf/734695
forcing function to act like an unbound method dumps core (2003-05-13)
	http://python.org/sf/736892
Interpreter crash: sigfpe on Alpha (2003-05-14)
	http://python.org/sf/738066
test_long failure (2003-05-22)
	http://python.org/sf/741806
WeakKeyDictionary __delitem__ uses iterkeys (2003-05-24)
	http://python.org/sf/742860
Memory fault on complex weakref/weakkeydict delete (2003-05-24)
	http://python.org/sf/742911

Closed Patches
--------------

fix test_long failure on OSF/1 (2003-04-10)
	http://python.org/sf/719359
Fixes for setup.py in Mac/OSX/Docs (2003-04-27)
	http://python.org/sf/728744
Pydoc.py fixes links (2003-05-10)
	http://python.org/sf/735694
HP-UX support for unixccompiler.py (2003-05-20)
	http://python.org/sf/740301
check for true in diffrent paths, -pthread support (2003-05-24)
	http://python.org/sf/742741


From guido@python.org  Sun Jun  1 13:57:01 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 01 Jun 2003 08:57:01 -0400
Subject: [Python-Dev] Descriptor write-up [Draft: Please comment]
In-Reply-To: "Your message of Sun, 01 Jun 2003 06:32:36 EDT."
 <5.1.0.14.0.20030601061239.034c3d00@mail.telecommunity.com>
References: <5.1.0.14.0.20030601061239.034c3d00@mail.telecommunity.com>
Message-ID: <200306011257.h51Cv1231568@pcp02138704pcs.reston01.va.comcast.net>

(I'd like to review this more carefully when I have more time, but one
thing jumped out at me:)

[Phillip Eby]
> It would be a good idea to add some information about "data" and
> "non-data" descriptors, and the differences of how their attribute
> lookup is processed.  I recently posted here about the "attribute
> lookup process" or something to that effect, which covered this.
> Understanding data vs. non-data descriptors is important if you want
> to do pretty much anything with descriptors beyond what property()
> does.

Note that I recently changed the treatment of data descriptors by
super() in 2.3.  typeobject.c rev 2.227/2.228:

----------------------------
revision 2.228
date: 2003/04/16 20:01:36;  author: gvanrossum;  state: Exp;  lines: +1 -1
Sigh.  The crucial change was still missing from the previous
checkin. :-(
----------------------------
revision 2.227
date: 2003/04/16 19:40:58;  author: gvanrossum;  state: Exp;  lines: +10 -4
- super() no longer ignores data descriptors, except __class__.  See
  the thread started at
  http://mail.python.org/pipermail/python-dev/2003-April/034338.html
----------------------------

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


From guido@python.org  Sun Jun  1 14:02:58 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 01 Jun 2003 09:02:58 -0400
Subject: [Python-Dev] Descriptor write-up [Draft: Please comment]
In-Reply-To: "Your message of Sun, 01 Jun 2003 11:45:16 BST."
 <2mof1if54z.fsf@starship.python.net>
References: <000901c32818$4fd52240$125ffea9@oemcomputer>
 <2mof1if54z.fsf@starship.python.net>
Message-ID: <200306011302.h51D2wL31587@pcp02138704pcs.reston01.va.comcast.net>

> Something about data descriptors (ones defining __set__) and method
> descriptors (ones not defining __set__) and their differences would be
> cool (particularly as this is something I don't quite understand!).

The main difference is that a non-data descriptor (they're not just
for methods) can be overridden by something in the instance __dict__,
while a data descriptor *always* overrides the instance __dict__.

This is done mostly for backwards compatibility, although it is useful
enough to call it a feature: you can define a method, and then assign
some other function (or callable) to the corresponding instance
variable, and this will hide the method *for that instance*.  (Sort of
like treating the instance as a subclass of the class, but not
quite. :-)

Data descriptors exist so that you can also have a different behavior,
which is also useful: setting the attribute calls the data
descriptor's __set__ method and doesn't affect the instance __dict__.
This is so that you can implement properties without overriding
__setattr__ (the horrible overkill hack that had to be used before 2.2
to trap setting even a single attribute).

And note that to create a read-only attribute, you create a data
descriptor whose __set__ raises an exception.  (This explains why a
property which has only a 'get' function still has the __set__
attribute.)

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


From guido@python.org  Sun Jun  1 14:16:07 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 01 Jun 2003 09:16:07 -0400
Subject: [Python-Dev] Algoritmic Complexity Attack on Python
In-Reply-To: "Your message of Sun, 01 Jun 2003 01:32:36 EDT."
 <LNBBLJKPBEHFEDALKOLCOEHJEIAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCOEHJEIAB.tim.one@comcast.net>
Message-ID: <200306011316.h51DG7J31627@pcp02138704pcs.reston01.va.comcast.net>

> [Guido]
> > Of course, such programs are already vulnerable to changes in the hash
> > implementation between Python versions (which has happened before).

[Tim]
> Last Thursday, Jim and I speculated about adding a persistent set
> type to Zope, implemented via an IOBTree under the covers, mapping
> int hash codes to lists of elements.  I'm sure someone else has
> already done something "like that"; I know I have in the past, but
> only to run monstrously large hash-function evaluation tests, where
> I needed to accumulate results across multiple runs.

I hope I can dissuade you from using Python's default hash codes; they
differ across platforms with different word lengths, too.  I don't
know enough about the requirements for this proposed persistent set
type; perhaps it would be acceptable to require that the set elements
define a method that returns a unique identifier which is an immutable
object using only Python built-in types?

> It's curious that persistence schemes are fragile in areas Python
> doesn't really care about, like how objects of different types
> compare to each other, how class instances that don't define __cmp__
> compare to each other, and in exactly which bit pattern
> hash(whatever) returns.

I doubt this is a coincidence.  When designing Python's run time, I
was very well aware of process boundaries and lifetime, and used them
to limit the scope of universal truths.  I wasn't really thinking of
persistence.

> In Python 3 it may be nice to define the results of such things more
> carefully in platform- and release-independent ways -- or maybe to
> raise exceptions instead of making results up, forcing users to
> confront the issues explicitly.  Lots of tradeoffs here ...

For comparisons, I've long considered the current "everything can be
ordered with respect to everything else" paradigm broken, and for 3.0
I plan to break this, allowing only == and != comparisons between
objects of different types that don't specifically cater to cross-type
comparisons (the default being unequal if the types differ).  Ordering
comparisons will default to an exception.

But this won't affect hashing; I don't think I'd like to see the hash
function fixed by the language standard, so the hash function may
still vary between releases (or between runs, for Python
implementations that follow Scott's recommendation).

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


From dave@boost-consulting.com  Sun Jun  1 16:00:56 2003
From: dave@boost-consulting.com (David Abrahams)
Date: Sun, 01 Jun 2003 11:00:56 -0400
Subject: [Python-Dev] more-precise instructions for "Python.h first"?
In-Reply-To: <m3brxijlhn.fsf@mira.informatik.hu-berlin.de> (
 =?iso-8859-1?q?Martin_v._L=F6wis's_message_of?= "01 Jun 2003 09:38:28
 +0200")
References: <uvfvrrxow.fsf@boost-consulting.com>
 <m34r3baxna.fsf@mira.informatik.hu-berlin.de>
 <ullwmkbra.fsf@boost-consulting.com>
 <m3brxijlhn.fsf@mira.informatik.hu-berlin.de>
Message-ID: <un0h1hmfr.fsf@boost-consulting.com>

martin@v.loewis.de (Martin v. L=F6wis) writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> The current rule doesn't work for me, but I'd like to be following
>> _some_ sanctioned rule to reduce the chance of problems today and in
>> the future. I'm making an educated guess that the rule is much
>> more-sweeping than Python development needs it to be.  Isn't there
>> some Python internal configuration header which can be #included first
>> and which will accomplish all the same things as far as system-header
>> inclusion order is concerned?
>
> I can't think of a less strict rule that is still comprehensible. I
> did not comprehend the wording that you first proposed, since it
> referred to preconditions that are fuzzy (what is xxxx.h?)

I'm asking you to tell me.  Maybe it's pyconfig.h.

> If you come up with a wording of a less strict rule, I can try to
> guess whether that rule would also work, on the systems I care about.
> In drafting such wording, keep in mind that the primary motivation for
> this rule is LFS support, where Python wants to select the 64-bit API
> (aka "large file") on systems that support that. So any system header
> that could potentially be affected by LFS selection can only be
> included after LFS selection has been done.

That's a helpful nugget.  So which Python header(s) are responsible
for LFS selection?

--=20
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From aahz@pythoncraft.com  Sun Jun  1 16:52:58 2003
From: aahz@pythoncraft.com (Aahz)
Date: Sun, 1 Jun 2003 11:52:58 -0400
Subject: [Python-Dev] Descriptor write-up    [Draft:  Please comment]
In-Reply-To: <000901c32818$4fd52240$125ffea9@oemcomputer>
References: <000901c32818$4fd52240$125ffea9@oemcomputer>
Message-ID: <20030601155258.GB6313@panix.com>

On Sun, Jun 01, 2003, Raymond Hettinger wrote:
>
> In the spirit of Michele Simionato's write-up on method resolution
> order, I've written up almost everything I know about descriptors:
>
> http://tinyurl.com/d63d

Cool!  Haven't had a chance to look at it, but I'd suggest sticking with
a canonical URL since it isn't very long:
http://users.rcn.com/python/download/Descriptor.htm
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"In many ways, it's a dull language, borrowing solid old concepts from
many other languages & styles:  boring syntax, unsurprising semantics,
few automatic coercions, etc etc.  But that's one of the things I like
about it."  --Tim Peters on Python, 16 Sep 93


From pje@telecommunity.com  Sun Jun  1 17:31:07 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Sun, 01 Jun 2003 12:31:07 -0400
Subject: [Python-Dev] Descriptor write-up [Draft: Please comment]
In-Reply-To: <200306011257.h51Cv1231568@pcp02138704pcs.reston01.va.comca
 st.net>
References: <"Your message of Sun, 01 Jun 2003 06:32:36 EDT." <5.1.0.14.0.20030601061239.034c3d00@mail.telecommunity.com>
 <5.1.0.14.0.20030601061239.034c3d00@mail.telecommunity.com>
Message-ID: <5.1.0.14.0.20030601122918.02504ec0@mail.telecommunity.com>

At 08:57 AM 6/1/03 -0400, Guido van Rossum wrote:
>(I'd like to review this more carefully when I have more time, but one
>thing jumped out at me:)
>
>[Phillip Eby]
> > It would be a good idea to add some information about "data" and
> > "non-data" descriptors, and the differences of how their attribute
> > lookup is processed.  I recently posted here about the "attribute
> > lookup process" or something to that effect, which covered this.
> > Understanding data vs. non-data descriptors is important if you want
> > to do pretty much anything with descriptors beyond what property()
> > does.
>
>Note that I recently changed the treatment of data descriptors by
>super() in 2.3.  typeobject.c rev 2.227/2.228:

And an important change it is.  If you define methods on metaclasses that 
might also be defined by their instances (i.e. the classes) on behalf of 
*their* instances, the only way to get this to work right is to use data 
descriptors for the metaclass level methods.  Which then means super() 
breaks, so for 2.2 I have a custom 'super()' to work with data 
descriptors.  I rather wish you'd considered it a bugfix rather than a new 
feature.  :)



From martin@v.loewis.de  Sun Jun  1 17:55:26 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 01 Jun 2003 18:55:26 +0200
Subject: [Python-Dev] more-precise instructions for "Python.h first"?
In-Reply-To: <un0h1hmfr.fsf@boost-consulting.com>
References: <uvfvrrxow.fsf@boost-consulting.com>
 <m34r3baxna.fsf@mira.informatik.hu-berlin.de>
 <ullwmkbra.fsf@boost-consulting.com>
 <m3brxijlhn.fsf@mira.informatik.hu-berlin.de>
 <un0h1hmfr.fsf@boost-consulting.com>
Message-ID: <m3vfvp7n5t.fsf@mira.informatik.hu-berlin.de>

David Abrahams <dave@boost-consulting.com> writes:

> That's a helpful nugget.  So which Python header(s) are responsible
> for LFS selection?

These are in pyconfig.h, namely _LARGEFILE_SOURCE and _FILE_OFFSET_BITS.

Regards,
Martin


From gustav@morpheus.demon.co.uk  Sun Jun  1 17:17:10 2003
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sun, 01 Jun 2003 17:17:10 +0100
Subject: [Python-Dev] Re: Introduction
References: <Pine.LNX.4.44.0305281548150.19024-100000@devserv.devel.redhat.com> <47C92342-91E5-11D7-BD8E-00039344A0EC@wayforward.net>
Message-ID: <of1hg4c9.fsf@morpheus.demon.co.uk>

Terence Way <terry@wayforward.net> writes:

> On Wednesday, May 28, 2003, at 04:55  PM, Peter Jones wrote:
>
>> That being said, you still haven't explained *why* contracts belong
>> in docstrings (or in documentation in general). They are executable
>> code; why not treat them as such?
>>
> Okay, the whole docstring vs syntax thing, and I'm going to quote
> liberally from Bertrand Meyer's Object Oriented Software
> Construction, 1st edition, 7.9 Using Assertions.

Note: I'm *not* a fan of Eiffel-style formal pre and post conditions. 
I probably wouldn't use them, personally. But as I could end up
dealing with others' code which uses such a feature if it was added, I
do have an interest. Also, I haven't read the PEP yet (I'm offline
right now).

But I disagree fairly strongly with the idea of having pre/post
conditions in docstrings. That is *not* what docstrings are for.
Docstrings are documentation, not arbitrary metadata.

How about this as a proposal? Attach pre and post conditions to a
functions as function attributes. A silly example:


    def f():
        pass

    def pre():
        assert True
    f.pre = pre

    def post():
        assert True
    f.post = post

This is a bit wordy, but entirely doable with Python as it stands and
the conditions are syntax checked at definition time, just like they
should be. If pre/post conditions turn out to be so useful that they
deserve a more concise syntax, *that's* the time to propose better
syntax. (One obvious possibility would be to allow more flexibility in
def statements, so that

    def f.post():
        whatever

becomes possible.)

Paul.
-- 
This signature intentionally left blank



From gward@python.net  Sun Jun  1 22:57:00 2003
From: gward@python.net (Greg Ward)
Date: Sun, 1 Jun 2003 17:57:00 -0400
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
In-Reply-To: <200305292229.h4TMTdU19567@odiug.zope.com>
References: <20030529215652.GB28065@cthulhu.gerg.ca> <200305292229.h4TMTdU19567@odiug.zope.com>
Message-ID: <20030601215700.GA3217@cthulhu.gerg.ca>

On 29 May 2003, Guido van Rossum said:
> Alas, no change.  Still some squeaks from the speaker followed by a
> hanging process:

Well, my recent ossaudiodev changes wouldn't have changed anything if
ossaudiodev is completely hosed.  However, I've finally gotten around to
writing my pure C OSS test program.  It's checked in under
sandbox/audiotest.  Please give it a try!

  cd nondist/sandbox
  cvs up -dP
  cd audiotest
  make && ./audiotest

If *that* doesn't give sensible results, then we can't blame ossaudiodev
for the fact that it doesn't work on your box.

Err, the same goes for anyone with a Linux, FreeBSD, or OpenBSD box and
audio hardware: can y'all give the above a try and let me know how it
works for you?  Especially if you've had problems with ossaudiodev in
the past (hello, Jeremy).  I've tried to code to
lowest-common-denominator audio hardware, but that's easier said than
done.

        Greg
-- 
Greg Ward <gward@python.net>                         http://www.gerg.ca/
And now for something completely different.


From Raymond Hettinger" <python@rcn.com  Sun Jun  1 23:02:19 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Sun, 1 Jun 2003 18:02:19 -0400
Subject: [Python-Dev] Descriptor write-up [second draft]
Message-ID: <010c01c32889$796ca620$125ffea9@oemcomputer>

Thanks for the first round of comments.
Here is a second draft:

http://users.rcn.com/python/download/Descriptor.htm

Changes:

* various grammatical, punctuation, etc
* changed variable names between examples
* discuss data and non-data descriptors
* show the precedence of the data vs non-data descriptors
* moved the C code references inside the Python code
* eliminated the python code for obj.__getattribute__
   because code was complex enough to hide the discussion points

To do:

When this one is done, will use it as a basis for 
updating the official docs.

The final version of this will be done through
docutils with reStructured text.  That ought to
take care of the vagaries of converting a Word
document to html.


Raymond


From barry@python.org  Sun Jun  1 23:38:54 2003
From: barry@python.org (Barry Warsaw)
Date: Sun, 1 Jun 2003 18:38:54 -0400
Subject: [Python-Dev] Re: Introduction
In-Reply-To: <of1hg4c9.fsf@morpheus.demon.co.uk>
Message-ID: <D353DB98-9481-11D7-9F48-003065EEFAC8@python.org>

On Sunday, June 1, 2003, at 12:17 PM, Paul Moore wrote:
> Note: I'm *not* a fan of Eiffel-style formal pre and post conditions.
> I probably wouldn't use them, personally. But as I could end up
> dealing with others' code which uses such a feature if it was added, I
> do have an interest. Also, I haven't read the PEP yet (I'm offline
> right now).
>
> But I disagree fairly strongly with the idea of having pre/post
> conditions in docstrings. That is *not* what docstrings are for.
> Docstrings are documentation, not arbitrary metadata.
>
> How about this as a proposal? Attach pre and post conditions to a
> functions as function attributes. A silly example:
>
>
>     def f():
>         pass
>
>     def pre():
>         assert True
>     f.pre = pre
>
>     def post():
>         assert True
>     f.post = post
>
> This is a bit wordy, but entirely doable with Python as it stands and
> the conditions are syntax checked at definition time, just like they
> should be. If pre/post conditions turn out to be so useful that they
> deserve a more concise syntax, *that's* the time to propose better
> syntax. (One obvious possibility would be to allow more flexibility in
> def statements, so that
>
>     def f.post():
>         whatever
>
> becomes possible.)

Although I haven't played with it much, in the back of my mind, I think 
descriptors might be the right implementation technique for this.  And 
the syntax that seems to keep coming up is something like:

def f(x, y) [pre, post]:
   foo()

For other reasons, I'm finding that I'd really like to see this syntax 
for function decorators embodied in its own PEP.

-Barry



From agthorr@barsoom.org  Sun Jun  1 23:59:58 2003
From: agthorr@barsoom.org (Agthorr)
Date: Sun, 1 Jun 2003 15:59:58 -0700
Subject: [Python-Dev] Re: Introduction
In-Reply-To: <of1hg4c9.fsf@morpheus.demon.co.uk>
References: <Pine.LNX.4.44.0305281548150.19024-100000@devserv.devel.redhat.com> <47C92342-91E5-11D7-BD8E-00039344A0EC@wayforward.net> <of1hg4c9.fsf@morpheus.demon.co.uk>
Message-ID: <20030601225958.GA21604@barsoom.org>

On Sun, Jun 01, 2003 at 05:17:10PM +0100, Paul Moore wrote:
> But I disagree fairly strongly with the idea of having pre/post
> conditions in docstrings. That is *not* what docstrings are for.
> Docstrings are documentation, not arbitrary metadata.
> 
> How about this as a proposal? Attach pre and post conditions to a
> functions as function attributes. A silly example:

FWIW, I stumbled across an implementation of contracts for Python that
works more or less in the manner you describe:

http://www.nongnu.org/pydbc/

I agree that contracts shouldn't be in docstrings.  I confess though,
that is because I know editor indenting and syntax highlighting won't
handle it smoothly ;)

-- Agthorr


From dave@boost-consulting.com  Mon Jun  2 00:04:24 2003
From: dave@boost-consulting.com (David Abrahams)
Date: Sun, 01 Jun 2003 19:04:24 -0400
Subject: [Python-Dev] more-precise instructions for "Python.h first"?
In-Reply-To: <m3vfvp7n5t.fsf@mira.informatik.hu-berlin.de> (
 =?iso-8859-1?q?Martin_v._L=F6wis's_message_of?= "01 Jun 2003 18:55:26
 +0200")
References: <uvfvrrxow.fsf@boost-consulting.com>
 <m34r3baxna.fsf@mira.informatik.hu-berlin.de>
 <ullwmkbra.fsf@boost-consulting.com>
 <m3brxijlhn.fsf@mira.informatik.hu-berlin.de>
 <un0h1hmfr.fsf@boost-consulting.com>
 <m3vfvp7n5t.fsf@mira.informatik.hu-berlin.de>
Message-ID: <u1xyds8lj.fsf@boost-consulting.com>

martin@v.loewis.de (Martin v. L=F6wis) writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> That's a helpful nugget.  So which Python header(s) are responsible
>> for LFS selection?
>
> These are in pyconfig.h, namely _LARGEFILE_SOURCE and _FILE_OFFSET_BITS.

Fabulous.  I'd like the rule changed from:

   "Since Python may define some pre-processor definitions which
   affect the standard headers on some systems, you must include
   Python.h before any standard headers are included."

to:

   "Since Python may define some pre-processor definitions which
   affect the standard headers on some systems, you must include
   Python.h or pyconfig.h (Python's configuration header), before any
   standard headers are included."

That is precise wording, taken from
http://www.python.org/doc/current/api/includes.html

--=20
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From python@rcn.com  Mon Jun  2 01:44:00 2003
From: python@rcn.com (Raymond Hettinger)
Date: Sun, 1 Jun 2003 20:44:00 -0400
Subject: [Python-Dev] Re: Introduction
References: <Pine.LNX.4.44.0305281548150.19024-100000@devserv.devel.redhat.com> <47C92342-91E5-11D7-BD8E-00039344A0EC@wayforward.net> <of1hg4c9.fsf@morpheus.demon.co.uk> <20030601225958.GA21604@barsoom.org>
Message-ID: <001101c328a0$0f796c00$125ffea9@oemcomputer>

> FWIW, I stumbled across an implementation of contracts for Python that
> works more or less in the manner you describe:

With the new surge of interest in metaclasses, I expect many
competing DBC implementations to come into existence.  An early
commitment to one of them may preclude better ideas from
getting a chance.

Another thought is that all of the machinery is in place to enable
a library of cooperating metaclass tools as envisioned by
Forman and Danforth's metaclass book.  Any metaclass work
included in the distribution ought to make allowances for
being included side-by-side with threadsafety metaclasses,
logging metaclasses, auto property creators, auto delegators,
and such.

In summary, I prefer that DBC not be PEPed.  Instead, let things
grow on SF, the cookbook, the vaults, and private offerings.

'nuff said,


Raymond Hettinger


From guido@python.org  Mon Jun  2 02:01:25 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 01 Jun 2003 21:01:25 -0400
Subject: [Python-Dev] Re: Introduction
In-Reply-To: "Your message of Sun, 01 Jun 2003 20:44:00 EDT."
 <001101c328a0$0f796c00$125ffea9@oemcomputer>
References: <Pine.LNX.4.44.0305281548150.19024-100000@devserv.devel.redhat.com>
 <47C92342-91E5-11D7-BD8E-00039344A0EC@wayforward.net>
 <of1hg4c9.fsf@morpheus.demon.co.uk> <20030601225958.GA21604@barsoom.org>
 <001101c328a0$0f796c00$125ffea9@oemcomputer>
Message-ID: <200306020101.h5211PF03122@pcp02138704pcs.reston01.va.comcast.net>

> With the new surge of interest in metaclasses, I expect many
> competing DBC implementations to come into existence.  An early
> commitment to one of them may preclude better ideas from
> getting a chance.
> 
> Another thought is that all of the machinery is in place to enable
> a library of cooperating metaclass tools as envisioned by
> Forman and Danforth's metaclass book.  Any metaclass work
> included in the distribution ought to make allowances for
> being included side-by-side with threadsafety metaclasses,
> logging metaclasses, auto property creators, auto delegators,
> and such.
> 
> In summary, I prefer that DBC not be PEPed.  Instead, let things
> grow on SF, the cookbook, the vaults, and private offerings.

Good suggestions!  This can be done many ways.  Let's find ot which
works best.

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


From guido@python.org  Mon Jun  2 02:23:00 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 01 Jun 2003 21:23:00 -0400
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
In-Reply-To: "Your message of Sun, 01 Jun 2003 17:57:00 EDT."
 <20030601215700.GA3217@cthulhu.gerg.ca>
References: <20030529215652.GB28065@cthulhu.gerg.ca>
 <200305292229.h4TMTdU19567@odiug.zope.com>
 <20030601215700.GA3217@cthulhu.gerg.ca>
Message-ID: <200306020123.h521N0x09961@pcp02138704pcs.reston01.va.comcast.net>

> On 29 May 2003, Guido van Rossum said:
> > Alas, no change.  Still some squeaks from the speaker followed by a
> > hanging process:
> 
> Well, my recent ossaudiodev changes wouldn't have changed anything if
> ossaudiodev is completely hosed.  However, I've finally gotten around to
> writing my pure C OSS test program.  It's checked in under
> sandbox/audiotest.  Please give it a try!
> 
>   cd nondist/sandbox
>   cvs up -dP
>   cd audiotest
>   make && ./audiotest
> 
> If *that* doesn't give sensible results, then we can't blame ossaudiodev
> for the fact that it doesn't work on your box.

That gives sensible results.  The mystery continues...

But I wonder if there's a difference between my home and my work box?
The ossaudiodev test runs fine on my home box now, but it hung on my
work box last week; I seem to recall that it failed on my home box
before your last fix to the C module.

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


From tim.one@comcast.net  Mon Jun  2 03:12:11 2003
From: tim.one@comcast.net (Tim Peters)
Date: Sun, 01 Jun 2003 22:12:11 -0400
Subject: [Python-Dev] Algoritmic Complexity Attack on Python
In-Reply-To: <200306011316.h51DG7J31627@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCKELAEIAB.tim.one@comcast.net>

[Guido]
> I hope I can dissuade you from using Python's default hash codes;

It's easy to dissuade me; it's Jim we have to worry about <wink>.

> they differ across platforms with different word lengths, too.  I don't
> know enough about the requirements for this proposed persistent set
> type; perhaps it would be acceptable to require that the set elements
> define a method that returns a unique identifier which is an immutable
> object using only Python built-in types?

I hope so, but don't know the use cases well enough to guess whether that
would be considered good enough.

> ...
> I doubt this is a coincidence.  When designing Python's run time, I
> was very well aware of process boundaries and lifetime, and used them
> to limit the scope of universal truths.  I wasn't really thinking of
> persistence.

Neither was I <wink>.

> ...
> For comparisons, I've long considered the current "everything can be
> ordered with respect to everything else" paradigm broken, and for 3.0
> I plan to break this, allowing only == and != comparisons between
> objects of different types that don't specifically cater to cross-type
> comparisons (the default being unequal if the types differ).  Ordering
> comparisons will default to an exception.

That would go a long way toward keeping people out of trouble with
persistent BTree-based structures.

> But this won't affect hashing; I don't think I'd like to see the hash
> function fixed by the language standard, so the hash function may
> still vary between releases (or between runs, for Python
> implementations that follow Scott's recommendation).

For Python 3 I hope we (you) can consider another line of flexibility too:
sometimes when I build a hash table, I want an __eq__ that isn't "the
natural" __eq__ for the key objects.  For example, using a dict to partition
objects by equivalence class wants to use the equivalence relation of
interest at the moment.  This implies a specific dict may want to use a
"non-standard" __hash__ too.  Hiding the real objects in wrapper objects
works for this purpose, of course, but sometimes it would be a lot more
convenient to pass hash and eq functions to a dict's constructor.



From terry@wayforward.net  Mon Jun  2 03:19:53 2003
From: terry@wayforward.net (Terence Way)
Date: Sun, 1 Jun 2003 22:19:53 -0400
Subject: [Python-Dev] Re: Introduction
In-Reply-To: <200306020101.h5211PF03122@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <B25C4DDA-94A0-11D7-BD8E-00039344A0EC@wayforward.net>

On Sunday, June 1, 2003, at 09:01  PM, Guido van Rossum wrote:

>> In summary, I prefer that DBC not be PEPed.  Instead, let things
>> grow on SF, the cookbook, the vaults, and private offerings.
>
> Good suggestions!  This can be done many ways.  Let's find ot which
> works best.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>

Sigh...

PEP withdrawn.

I would just like to point out, however, that the challenge with DBC
is *not* how to install contracts, whether that's done with meta-
classes, attributes, whatever.  The challenges are 1) dual use as code
and documentation, and 2) correct behavior under inheritance.

The problem with multiple implementations is that they may not work
together under inheritance, ie all super-class invariants might
not be checked, all overridden post-conditions not checked, if the
superclass and the derived class use different implementations.

What I'll do now is:
1. clean up the loose ends on my implementation; and
2. continue to write contracts for the Python standard library.  I've
    already found 1 bug :-) a full report due soon(ish).

Cheers.



From drifty@alum.berkeley.edu  Mon Jun  2 03:55:24 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Sun, 01 Jun 2003 19:55:24 -0700
Subject: [Python-Dev] Descriptor write-up [second draft]
In-Reply-To: <010c01c32889$796ca620$125ffea9@oemcomputer>
References: <010c01c32889$796ca620$125ffea9@oemcomputer>
Message-ID: <3EDABC9C.6010601@ocf.berkeley.edu>

Raymond Hettinger wrote:
> Thanks for the first round of comments.
> Here is a second draft:
> 
> http://users.rcn.com/python/download/Descriptor.htm
> 

Once again, good job, Raymond!

But now, to the nit-picky stuff.  =)  For the section entitled 
"Definition and Introduction", I don't like it reading like its 
namesake.  I feel like the intro paragraphs should come first to let you 
know why you should be learning this stuff and then give the general 
overview of what a descriptor is.

In "Descriptor Protocol" it feels abrupt when you mention how to make a 
data descriptor read-only.  I feel like it should read more like "To 
make a read-only data descriptor, define both __get__ and __set__ with 
the __set__ raising an AttributeError exception when called since a data 
descriptor must define *some* __set__ method", or something like that. 
It just comes off as some random piece of info with no tie into why it 
is that way.

For the "Properties" the __get__ parameter list you use the name 'type'. 
  Unfortunately that masks the built-in.  Not a big issue but people 
might copy this code and such so having it as correct as possible won't 
hurt.

Otherwise its a great piece.

-Brett



From python@rcn.com  Mon Jun  2 04:51:51 2003
From: python@rcn.com (Raymond Hettinger)
Date: Sun, 1 Jun 2003 23:51:51 -0400
Subject: [Python-Dev] Descriptor write-up [second draft]
References: <010c01c32889$796ca620$125ffea9@oemcomputer> <3EDABC9C.6010601@ocf.berkeley.edu>
Message-ID: <002001c328ba$64bf69c0$125ffea9@oemcomputer>

> Once again, good job, Raymond!
> 
> But now, to the nit-picky stuff.  =)  For the section entitled 
> "Definition and Introduction", I don't like it reading like its 
> namesake.  I feel like the intro paragraphs should come first to let you 
> know why you should be learning this stuff and then give the general 
> overview of what a descriptor is.

"All I want to know is what a descriptor is" --> "Okay, read the definition"
That's the Raymond way -- No character development, foreshadowing, false climaxes, nada.


> In "Descriptor Protocol" it feels abrupt when you mention how to make a 
> data descriptor read-only.  I feel like it should read more like "To 
> make a read-only data descriptor, define both __get__ and __set__ with 
> the __set__ raising an AttributeError exception when called since a data 
> descriptor must define *some* __set__ method", or something like that. 
> It just comes off as some random piece of info with no tie into why it 
> is that way.

Fixed.

> 
> For the "Properties" the __get__ parameter list you use the name 'type'. 
>   Unfortunately that masks the built-in.  Not a big issue but people 
> might copy this code and such so having it as correct as possible won't 
> hurt.

Unfortunately, type *is* the advertised parameter name.
Fixed it anyway.

> Otherwise its a great piece.

Thanks.


Raymond

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################


From martin@v.loewis.de  Mon Jun  2 06:41:38 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 02 Jun 2003 07:41:38 +0200
Subject: [Python-Dev] more-precise instructions for "Python.h first"?
In-Reply-To: <u1xyds8lj.fsf@boost-consulting.com>
References: <uvfvrrxow.fsf@boost-consulting.com>
 <m34r3baxna.fsf@mira.informatik.hu-berlin.de>
 <ullwmkbra.fsf@boost-consulting.com>
 <m3brxijlhn.fsf@mira.informatik.hu-berlin.de>
 <un0h1hmfr.fsf@boost-consulting.com>
 <m3vfvp7n5t.fsf@mira.informatik.hu-berlin.de>
 <u1xyds8lj.fsf@boost-consulting.com>
Message-ID: <m3znl1594d.fsf@mira.informatik.hu-berlin.de>

David Abrahams <dave@boost-consulting.com> writes:

>    "Since Python may define some pre-processor definitions which
>    affect the standard headers on some systems, you must include
>    Python.h or pyconfig.h (Python's configuration header), before any
>    standard headers are included."

Ok. I think this rule may break on SGI, where Python.h has

#if defined(__sgi) && defined(WITH_THREAD) && !defined(_SGI_MP_SOURCE)
#define _SGI_MP_SOURCE
#endif

Now, I have never seen an SGI machine in my life, and I have no idea
what _SGI_MP_SOURCE is. However it seems that it is important that
this is defined before stdio.h is included (or perhaps it was
important at some point in time).

Apart from that, I can't find any problems with that rule (but there
may be problems that I'm overlooking). I recommend that you follow
this rule, anyway; if you discover any problems by doing so, please
let us know.

Regards,
Martin


From dalke@dalkescientific.com  Mon Jun  2 08:43:14 2003
From: dalke@dalkescientific.com (Andrew Dalke)
Date: Mon, 2 Jun 2003 01:43:14 -0600
Subject: [Python-Dev] BaseHTTPServer parsing
Message-ID: <DE102A46-94CD-11D7-B9B9-000393C92466@dalkescientific.com>

Hi,

   I would like to use the code in BaseHTTPServer to parse the incoming
message for Twisted.  One way is to write an adapter which looks like

class _ParseHTTPRequest(BaseHTTPServer.BaseHTTPRequestHandler):
   def __init__(self):
     # Don't worry about doing the real constructor; I just want access 
to
     # the 'parse_request' function.
     # I could also say "parse_request = 
BaseHTTPServer.BaseHTTPRequestHandler.parse_request
     pass

   def parse(self, raw_requestline, infile):
     self.raw_requestline = raw_requestline
     self.rfile = infile
     self.error_info = False
     self.parse_request()

   def send_error(self, code, message=None):
     self.error_info = (code, message)

def parse(raw_requestline, infile):
   p = _ParseHTTPRequest()
   p.parse(raw_requestline, infile)
   return p

# Then in the Twisted code

   def lineReceived(self, line):
     if self.__first_line:
       self.raw_requestline = line
       self.__first_line = 0
       self.rfile = StringIO()
     else:
       self.rfile.write(line + "\n")
       if line == "": # end of headers
         p = _ParseHTTPRequest()
         if p.error_info is not None:
            ... handle errors
         else:
            work with p.headers, p.comand, etc.


That should work, but I note that the 'parse_request' function is 
listed as
"internal", which I take to mean that people like me shouldn't make any
assumptions that it even exists, much less that I can make use of it 
for my
own nefarious reasons.

Can I get a better guarantee than that?  I ask because I would rather 
that
Twisted and Python work the same way (esp. since the Python code is 
generally
more robust).


					Andrew
					dalke@dalkescientific.com



From Jack.Jansen@cwi.nl  Mon Jun  2 10:02:32 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Mon, 2 Jun 2003 11:02:32 +0200
Subject: [Python-Dev] more-precise instructions for "Python.h first"?
In-Reply-To: <m3znl1594d.fsf@mira.informatik.hu-berlin.de>
Message-ID: <F1FD95F1-94D8-11D7-8D6E-0030655234CE@cwi.nl>

On Monday, Jun 2, 2003, at 07:41 Europe/Amsterdam, Martin v. L=F6wis=20
wrote:

> David Abrahams <dave@boost-consulting.com> writes:
>
>>    "Since Python may define some pre-processor definitions which
>>    affect the standard headers on some systems, you must include
>>    Python.h or pyconfig.h (Python's configuration header), before any
>>    standard headers are included."
>
> Ok. I think this rule may break on SGI, where Python.h has
>
> #if defined(__sgi) && defined(WITH_THREAD) && !defined(_SGI_MP_SOURCE)
> #define _SGI_MP_SOURCE
> #endif
>
> Now, I have never seen an SGI machine in my life, and I have no idea
> what _SGI_MP_SOURCE is. However it seems that it is important that
> this is defined before stdio.h is included (or perhaps it was
> important at some point in time).

This define seems to handle how concurrent access and locking of stdio=20=

data structures is handled (and, incidentally, also how errno is=20
declared in errno.h). So it does indeed seem important that this is in=20=

scope before including errno.h or stdio.h.

It should be easy enough to have configure stick the _SGI_MP_SOURCE=20
definition in pyconfig.h, if someone is willing to do the work. For me=20=

Pyhon stopped compiling on Irix a while ago, and I can't be bothered to=20=

look into it.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma=20
Goldman



From mwh@python.net  Mon Jun  2 10:08:34 2003
From: mwh@python.net (Michael Hudson)
Date: Mon, 02 Jun 2003 10:08:34 +0100
Subject: [Python-Dev] Re: Introduction
In-Reply-To: <D353DB98-9481-11D7-9F48-003065EEFAC8@python.org> (Barry
 Warsaw's message of "Sun, 1 Jun 2003 18:38:54 -0400")
References: <D353DB98-9481-11D7-9F48-003065EEFAC8@python.org>
Message-ID: <2mznl0978t.fsf@starship.python.net>

Barry Warsaw <barry@python.org> writes:

> Although I haven't played with it much, in the back of my mind, I
> think descriptors might be the right implementation technique for
> this.  And the syntax that seems to keep coming up is something like:
>
> def f(x, y) [pre, post]:
>    foo()
>
> For other reasons, I'm finding that I'd really like to see this syntax
> for function decorators embodied in its own PEP.

Well, I implemented it, so I've been sort of assuming that I'll be
writing the PEP.  However if someone else beats me to it, I'm not
going to be offended!  I'm not going to get to it in a hurry, TBH.

Cheers,
M.


-- 
  Richard Gabriel was wrong: worse is not better, lying is better.
  Languages and systems succeed in the marketplace to the extent that
  their proponents lie about what they can do.
                                       -- Tim Bradshaw, comp.lang.lisp


From guido@python.org  Mon Jun  2 14:23:42 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Jun 2003 09:23:42 -0400
Subject: [Python-Dev] BaseHTTPServer parsing
In-Reply-To: Your message of "Mon, 02 Jun 2003 01:43:14 MDT."
 <DE102A46-94CD-11D7-B9B9-000393C92466@dalkescientific.com>
References: <DE102A46-94CD-11D7-B9B9-000393C92466@dalkescientific.com>
Message-ID: <200306021323.h52DNhj03960@odiug.zope.com>

>    I would like to use the code in BaseHTTPServer to parse the incoming
> message for Twisted.  One way is to write an adapter which looks like
> 
> class _ParseHTTPRequest(BaseHTTPServer.BaseHTTPRequestHandler):
>    def __init__(self):
>      # Don't worry about doing the real constructor; I just want access 
> to
>      # the 'parse_request' function.
>      # I could also say "parse_request = 
> BaseHTTPServer.BaseHTTPRequestHandler.parse_request
>      pass
> 
>    def parse(self, raw_requestline, infile):
>      self.raw_requestline = raw_requestline
>      self.rfile = infile
>      self.error_info = False
>      self.parse_request()
> 
>    def send_error(self, code, message=None):
>      self.error_info = (code, message)
> 
> def parse(raw_requestline, infile):
>    p = _ParseHTTPRequest()
>    p.parse(raw_requestline, infile)
>    return p
> 
> # Then in the Twisted code
> 
>    def lineReceived(self, line):
>      if self.__first_line:
>        self.raw_requestline = line
>        self.__first_line = 0
>        self.rfile = StringIO()
>      else:
>        self.rfile.write(line + "\n")
>        if line == "": # end of headers
>          p = _ParseHTTPRequest()
>          if p.error_info is not None:
>             ... handle errors
>          else:
>             work with p.headers, p.comand, etc.
> 
> 
> That should work, but I note that the 'parse_request' function is
> listed as "internal", which I take to mean that people like me
> shouldn't make any assumptions that it even exists, much less that I
> can make use of it for my own nefarious reasons.
> 
> Can I get a better guarantee than that?  I ask because I would
> rather that Twisted and Python work the same way (esp. since the
> Python code is generally more robust).

Can't you just copy the code?  I'm not sure I understand the desire to
share code here.  Given that it's labeled internal, there is the real
possibility (even though there are no plans ATM) that
BaseHTTPRequestHandler will be refactored so that your adapter stops
working.

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


From guido@python.org  Mon Jun  2 14:37:56 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Jun 2003 09:37:56 -0400
Subject: [Python-Dev] Algoritmic Complexity Attack on Python
In-Reply-To: Your message of "Sun, 01 Jun 2003 22:12:11 EDT."
 <LNBBLJKPBEHFEDALKOLCKELAEIAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCKELAEIAB.tim.one@comcast.net>
Message-ID: <200306021337.h52Dbuk04067@odiug.zope.com>

> For Python 3 I hope we (you) can consider another line of
> flexibility too: sometimes when I build a hash table, I want an
> __eq__ that isn't "the natural" __eq__ for the key objects.  For
> example, using a dict to partition objects by equivalence class
> wants to use the equivalence relation of interest at the moment.
> This implies a specific dict may want to use a "non-standard"
> __hash__ too.  Hiding the real objects in wrapper objects works for
> this purpose, of course, but sometimes it would be a lot more
> convenient to pass hash and eq functions to a dict's constructor.

Couldn't you write a dict-like class that does the wrapping for you?
I'm worried that adding such flexibility to dict will slow down the
common case.

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


From guido@python.org  Mon Jun  2 14:44:05 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Jun 2003 09:44:05 -0400
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
In-Reply-To: Your message of "Sun, 01 Jun 2003 21:23:00 EDT."
 <200306020123.h521N0x09961@pcp02138704pcs.reston01.va.comcast.net>
References: <20030529215652.GB28065@cthulhu.gerg.ca> <200305292229.h4TMTdU19567@odiug.zope.com> <20030601215700.GA3217@cthulhu.gerg.ca>
 <200306020123.h521N0x09961@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <200306021344.h52Di5510917@odiug.zope.com>

> > Well, my recent ossaudiodev changes wouldn't have changed anything if
> > ossaudiodev is completely hosed.  However, I've finally gotten around to
> > writing my pure C OSS test program.  It's checked in under
> > sandbox/audiotest.  Please give it a try!
> > 
> >   cd nondist/sandbox
> >   cvs up -dP
> >   cd audiotest
> >   make && ./audiotest
> > 
> > If *that* doesn't give sensible results, then we can't blame ossaudiodev
> > for the fact that it doesn't work on your box.
> 
> That gives sensible results.  The mystery continues...
> 
> But I wonder if there's a difference between my home and my work box?
> The ossaudiodev test runs fine on my home box now, but it hung on my
> work box last week; I seem to recall that it failed on my home box
> before your last fix to the C module.

Indeed, on my work box running ./audiotest says:

  opening /dev/dsp ... done
  audiotest: error: /dev/dsp: unable to set sample format to 8 (got 16)

ls -l /dev/dsp gives:

  crw-------    1 guido    root      14,   3 Apr 11  2002 /dev/dsp

which is about the same as it is on my home box.  Adding the x
permission doesn't change a thing.

Maybe the audio hardward on the work box simply isn't capable of doing
anything besides 16-bit samples?  According to hwbrowser, it is

  82801AA AC'97 Audio
  Manufacturer: Intel Corp.
  Driver: i810_audio
  Device: N/A

The home box (which works) is

  CRD-8400B
  Manufacturer: Unknown
  Driver: ignore
  Device: /dev/hdc

How's that for differences. :-0

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


From Anthony Baxter <anthony@interlink.com.au>  Mon Jun  2 15:47:10 2003
From: Anthony Baxter <anthony@interlink.com.au> (Anthony Baxter)
Date: Tue, 03 Jun 2003 00:47:10 +1000
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
In-Reply-To: <200306021344.h52Di5510917@odiug.zope.com>
Message-ID: <200306021447.h52ElBT19693@localhost.localdomain>

>>> Guido van Rossum wrote
> Maybe the audio hardward on the work box simply isn't capable of doing
> anything besides 16-bit samples?  According to hwbrowser, it is
> 
>   82801AA AC'97 Audio
>   Manufacturer: Intel Corp.
>   Driver: i810_audio
>   Device: N/A

That's the same as I've got in my Dell Latitude (running RH7.3) and
as far as I can tell, it's "give me 16 bit samples or I give you
squeaky chipmunk voice" (or an error). I'm hoping that upgrading to
RH9 will give a newer audiodriver (alsa, hopefully) that'll fix this.
(waiting for vmware upgrade to support RH9 first...)

Anthony

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



From sjoerd@acm.org  Mon Jun  2 16:18:57 2003
From: sjoerd@acm.org (Sjoerd Mullender)
Date: Mon, 02 Jun 2003 17:18:57 +0200
Subject: [Python-Dev] popen2.py strangeness
Message-ID: <20030602151858.162AB74230@indus.ins.cwi.nl>

I can't currently report this as a bug on SourceForge (down for
maintenance), so in the mean time we can discuss this here...

I just noticed the following behavior (current CVS):

+ python
Python 2.3b1+ (#37, Jun  2 2003, 11:34:36)
[GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import popen2
>>> a = popen2.Popen3('sleep 1', 1, -1)
>>> # wait more than one second to give the process time to exit
...
>>> b = popen2.Popen3('sleep 1', 1, -1)
>>> a.wait()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/ufs/sjoerd/src/python/Lib/popen2.py", line 86, in wait
    pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes
>>>

I would expect the a.wait() to return the exit status (or None) of the
first "sleep 1" command, but instead I get a traceback.

The reason is clear: in popen2.Popen3.__init__ the very first thing that
happens is a call to _cleanup() which does a poll() call on all active
instances.  If the process has died, the os.waitpid() call that poll()
does removes it from the OS's process table, so that a next os.waitpid()
on the same process id will fail.

I understand why the call to _cleanup() happens: defunct processes need
to be cleaned up, and if you only ever use the popen[234] factory
functions, the library needs to call os.waitpid for the created
processes.

However, it seems to me the above sequence of events is legitimate and
should be supported.  The question is: how?

-- Sjoerd Mullender <sjoerd@acm.org>


From guido@python.org  Mon Jun  2 16:38:04 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Jun 2003 11:38:04 -0400
Subject: [Python-Dev] popen2.py strangeness
In-Reply-To: Your message of "Mon, 02 Jun 2003 17:18:57 +0200."
 <20030602151858.162AB74230@indus.ins.cwi.nl>
References: <20030602151858.162AB74230@indus.ins.cwi.nl>
Message-ID: <200306021538.h52Fc4403937@odiug.zope.com>

> I just noticed the following behavior (current CVS):
> 
> + python
> Python 2.3b1+ (#37, Jun  2 2003, 11:34:36)
> [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import popen2
> >>> a = popen2.Popen3('sleep 1', 1, -1)
> >>> # wait more than one second to give the process time to exit
> ...
> >>> b = popen2.Popen3('sleep 1', 1, -1)
> >>> a.wait()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/ufs/sjoerd/src/python/Lib/popen2.py", line 86, in wait
>     pid, sts = os.waitpid(self.pid, 0)
> OSError: [Errno 10] No child processes
> >>>
> 
> I would expect the a.wait() to return the exit status (or None) of the
> first "sleep 1" command, but instead I get a traceback.
> 
> The reason is clear: in popen2.Popen3.__init__ the very first thing that
> happens is a call to _cleanup() which does a poll() call on all active
> instances.  If the process has died, the os.waitpid() call that poll()
> does removes it from the OS's process table, so that a next os.waitpid()
> on the same process id will fail.
> 
> I understand why the call to _cleanup() happens: defunct processes need
> to be cleaned up, and if you only ever use the popen[234] factory
> functions, the library needs to call os.waitpid for the created
> processes.
> 
> However, it seems to me the above sequence of events is legitimate and
> should be supported.  The question is: how?

Call os.waitpid() with an explicit pid argument?

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


From dalke@dalkescientific.com  Mon Jun  2 16:59:58 2003
From: dalke@dalkescientific.com (Andrew Dalke)
Date: Mon, 2 Jun 2003 09:59:58 -0600
Subject: [Python-Dev] BaseHTTPServer parsing
In-Reply-To: <200306021323.h52DNhj03960@odiug.zope.com>
Message-ID: <4282103E-9513-11D7-B9B9-000393C92466@dalkescientific.com>

Guido:
> Can't you just copy the code?  I'm not sure I understand the desire to
> share code here.  Given that it's labeled internal, there is the real
> possibility (even though there are no plans ATM) that
> BaseHTTPRequestHandler will be refactored so that your adapter stops
> working.

I could.  I was hoping to prevent some code duplication.  Since
both you all and Twisted people don't consider it useful, I'll just
go ahead and do that, with a comment to suggest staying in synch with
the Python libs.

					Andrew
					dalke@dalkescientific.com



From vladimir.marangozov@optimay.com  Mon Jun  2 18:10:42 2003
From: vladimir.marangozov@optimay.com (Marangozov, Vladimir (Vladimir))
Date: Mon, 2 Jun 2003 13:10:42 -0400
Subject: [Python-Dev] timsort?
Message-ID: <58C1D0B500F92D469E0D73994AB66D040107ECE3@GE0005EXCUAG01.ags.agere.com>

Guys, maybe some embarassing news: it looks like
in 2.2.3 final timsort in listobject.c is just plain
gone, and reverted to something quite old.  I can't
imagine this was done on purpose, as I would have
seen at least some discussion on the list.

Could you please double check. I wish I was wrong.

Vladimir


From sjoerd@acm.org  Mon Jun  2 18:11:56 2003
From: sjoerd@acm.org (Sjoerd Mullender)
Date: Mon, 02 Jun 2003 19:11:56 +0200
Subject: [Python-Dev] popen2.py strangeness
In-Reply-To: <200306021538.h52Fc4403937@odiug.zope.com>
References: <20030602151858.162AB74230@indus.ins.cwi.nl>
 <200306021538.h52Fc4403937@odiug.zope.com>
Message-ID: <20030602171156.78FC074230@indus.ins.cwi.nl>

On Mon, Jun 2 2003 Guido van Rossum wrote:

> > I just noticed the following behavior (current CVS):
> > 
> > + python
> > Python 2.3b1+ (#37, Jun  2 2003, 11:34:36)
> > [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import popen2
> > >>> a = popen2.Popen3('sleep 1', 1, -1)
> > >>> # wait more than one second to give the process time to exit
> > ...
> > >>> b = popen2.Popen3('sleep 1', 1, -1)
> > >>> a.wait()
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File "/ufs/sjoerd/src/python/Lib/popen2.py", line 86, in wait
> >     pid, sts = os.waitpid(self.pid, 0)
> > OSError: [Errno 10] No child processes
> > >>>
> > 
> > I would expect the a.wait() to return the exit status (or None) of the
> > first "sleep 1" command, but instead I get a traceback.
> > 
> > The reason is clear: in popen2.Popen3.__init__ the very first thing that
> > happens is a call to _cleanup() which does a poll() call on all active
> > instances.  If the process has died, the os.waitpid() call that poll()
> > does removes it from the OS's process table, so that a next os.waitpid()
> > on the same process id will fail.
> > 
> > I understand why the call to _cleanup() happens: defunct processes need
> > to be cleaned up, and if you only ever use the popen[234] factory
> > functions, the library needs to call os.waitpid for the created
> > processes.
> > 
> > However, it seems to me the above sequence of events is legitimate and
> > should be supported.  The question is: how?
> 
> Call os.waitpid() with an explicit pid argument?

popen2 does that, that's not the problem.  The problem is, after the
second call to popen2.Popen3 or popen2.Popen4 (possibly through the use
of the factory functions) the call to os.waitpid with explicit pid is
already done, so there is then no way to get the exit status anymore.
You can also not call os.waitpid (possibly through the poll() method)
just before calling popen2.Popen[34] because of race conditions (the
process might end just after your explicit call and just before the
implicit call in popen2.Popen[34]).

-- Sjoerd Mullender <sjoerd@acm.org>


From guido@python.org  Mon Jun  2 18:15:53 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Jun 2003 13:15:53 -0400
Subject: [Python-Dev] timsort?
In-Reply-To: Your message of "Mon, 02 Jun 2003 13:10:42 EDT."
 <58C1D0B500F92D469E0D73994AB66D040107ECE3@GE0005EXCUAG01.ags.agere.com>
References: <58C1D0B500F92D469E0D73994AB66D040107ECE3@GE0005EXCUAG01.ags.agere.com>
Message-ID: <200306021715.h52HFrk04891@odiug.zope.com>

> Guys, maybe some embarassing news: it looks like
> in 2.2.3 final timsort in listobject.c is just plain
> gone, and reverted to something quite old.  I can't
> imagine this was done on purpose, as I would have
> seen at least some discussion on the list.

timsort() is a 2.3 feature, not a 2.2 feature.

There's a SF project that contains a backport of timsort() to 2.2 though.

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


From guido@python.org  Mon Jun  2 18:25:45 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Jun 2003 13:25:45 -0400
Subject: [Python-Dev] popen2.py strangeness
In-Reply-To: Your message of "Mon, 02 Jun 2003 19:11:56 +0200."
 <20030602171156.78FC074230@indus.ins.cwi.nl>
References: <20030602151858.162AB74230@indus.ins.cwi.nl> <200306021538.h52Fc4403937@odiug.zope.com>
 <20030602171156.78FC074230@indus.ins.cwi.nl>
Message-ID: <200306021725.h52HPk404929@odiug.zope.com>

[Sjoerd]
> > > I just noticed the following behavior (current CVS):
> > > 
> > > + python
> > > Python 2.3b1+ (#37, Jun  2 2003, 11:34:36)
> > > [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
> > > Type "help", "copyright", "credits" or "license" for more information.
> > > >>> import popen2
> > > >>> a = popen2.Popen3('sleep 1', 1, -1)
> > > >>> # wait more than one second to give the process time to exit
> > > ...
> > > >>> b = popen2.Popen3('sleep 1', 1, -1)
> > > >>> a.wait()
> > > Traceback (most recent call last):
> > >   File "<stdin>", line 1, in ?
> > >   File "/ufs/sjoerd/src/python/Lib/popen2.py", line 86, in wait
> > >     pid, sts = os.waitpid(self.pid, 0)
> > > OSError: [Errno 10] No child processes
> > > >>>
> > > 
> > > I would expect the a.wait() to return the exit status (or None) of the
> > > first "sleep 1" command, but instead I get a traceback.
> > > 
> > > The reason is clear: in popen2.Popen3.__init__ the very first thing that
> > > happens is a call to _cleanup() which does a poll() call on all active
> > > instances.  If the process has died, the os.waitpid() call that poll()
> > > does removes it from the OS's process table, so that a next os.waitpid()
> > > on the same process id will fail.
> > > 
> > > I understand why the call to _cleanup() happens: defunct processes need
> > > to be cleaned up, and if you only ever use the popen[234] factory
> > > functions, the library needs to call os.waitpid for the created
> > > processes.
> > > 
> > > However, it seems to me the above sequence of events is legitimate and
> > > should be supported.  The question is: how?

[me]
> > Call os.waitpid() with an explicit pid argument?

[Sjoerd]
> popen2 does that, that's not the problem.  The problem is, after the
> second call to popen2.Popen3 or popen2.Popen4 (possibly through the use
> of the factory functions) the call to os.waitpid with explicit pid is
> already done, so there is then no way to get the exit status anymore.
> You can also not call os.waitpid (possibly through the poll() method)
> just before calling popen2.Popen[34] because of race conditions (the
> process might end just after your explicit call and just before the
> implicit call in popen2.Popen[34]).

Hm, it looks like wait() should add an "if self.sts < 0" around most
of its body, like poll().  In particular, this patch solves the
problem for me:

Index: popen2.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/popen2.py,v
retrieving revision 1.25
diff -c -c -r1.25 popen2.py
*** popen2.py	3 Jun 2002 15:58:31 -0000	1.25
--- popen2.py	2 Jun 2003 17:24:53 -0000
***************
*** 83,92 ****
  
      def wait(self):
          """Wait for and return the exit status of the child process."""
!         pid, sts = os.waitpid(self.pid, 0)
!         if pid == self.pid:
!             self.sts = sts
!             _active.remove(self)
          return self.sts
  
  
--- 83,93 ----
  
      def wait(self):
          """Wait for and return the exit status of the child process."""
!         if self.sts < 0:
!             pid, sts = os.waitpid(self.pid, 0)
!             if pid == self.pid:
!                 self.sts = sts
!                 _active.remove(self)
          return self.sts
  
  

Should I check it in, or is there more to it?

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


From tim@zope.com  Mon Jun  2 19:01:20 2003
From: tim@zope.com (Tim Peters)
Date: Mon, 2 Jun 2003 14:01:20 -0400
Subject: [Python-Dev] timsort?
In-Reply-To: <200306021715.h52HFrk04891@odiug.zope.com>
Message-ID: <BIEJKCLHCIOIHAGOKOLHCEAKFNAA.tim@zope.com>

[Guido]
> timsort() is a 2.3 feature, not a 2.2 feature.

Note that we switched from doing two minor releases per year, to something
like one minor release per two years (2.2 was released in 2001!).  timsort
is less than a year old, IIRC.  Since it can raise MemoryError where the 2.2
sort could not, and may compute different results on the same inputs, it was
much more a new feature than a bugfix.

> There's a SF project that contains a backport of timsort() to 2.2
> though.

    http://py-stablesort.sourceforge.net/



From sjoerd@acm.org  Mon Jun  2 20:07:39 2003
From: sjoerd@acm.org (Sjoerd Mullender)
Date: Mon, 02 Jun 2003 21:07:39 +0200
Subject: [Python-Dev] popen2.py strangeness
In-Reply-To: <200306021725.h52HPk404929@odiug.zope.com>
References: <20030602151858.162AB74230@indus.ins.cwi.nl> <200306021538.h52Fc4403937@odiug.zope.com> <20030602171156.78FC074230@indus.ins.cwi.nl>
 <200306021725.h52HPk404929@odiug.zope.com>
Message-ID: <20030602190739.79D3074230@indus.ins.cwi.nl>

On Mon, Jun 2 2003 Guido van Rossum wrote:

> [Sjoerd]
> > > > I just noticed the following behavior (current CVS):
> > > > 
> > > > + python
> > > > Python 2.3b1+ (#37, Jun  2 2003, 11:34:36)
> > > > [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
> > > > Type "help", "copyright", "credits" or "license" for more information.
> > > > >>> import popen2
> > > > >>> a = popen2.Popen3('sleep 1', 1, -1)
> > > > >>> # wait more than one second to give the process time to exit
> > > > ...
> > > > >>> b = popen2.Popen3('sleep 1', 1, -1)
> > > > >>> a.wait()
> > > > Traceback (most recent call last):
> > > >   File "<stdin>", line 1, in ?
> > > >   File "/ufs/sjoerd/src/python/Lib/popen2.py", line 86, in wait
> > > >     pid, sts = os.waitpid(self.pid, 0)
> > > > OSError: [Errno 10] No child processes
> > > > >>>
> > > > 
> > > > I would expect the a.wait() to return the exit status (or None) of the
> > > > first "sleep 1" command, but instead I get a traceback.
> > > > 
> > > > The reason is clear: in popen2.Popen3.__init__ the very first thing that
> > > > happens is a call to _cleanup() which does a poll() call on all active
> > > > instances.  If the process has died, the os.waitpid() call that poll()
> > > > does removes it from the OS's process table, so that a next os.waitpid()
> > > > on the same process id will fail.
> > > > 
> > > > I understand why the call to _cleanup() happens: defunct processes need
> > > > to be cleaned up, and if you only ever use the popen[234] factory
> > > > functions, the library needs to call os.waitpid for the created
> > > > processes.
> > > > 
> > > > However, it seems to me the above sequence of events is legitimate and
> > > > should be supported.  The question is: how?
> 
> [me]
> > > Call os.waitpid() with an explicit pid argument?
> 
> [Sjoerd]
> > popen2 does that, that's not the problem.  The problem is, after the
> > second call to popen2.Popen3 or popen2.Popen4 (possibly through the use
> > of the factory functions) the call to os.waitpid with explicit pid is
> > already done, so there is then no way to get the exit status anymore.
> > You can also not call os.waitpid (possibly through the poll() method)
> > just before calling popen2.Popen[34] because of race conditions (the
> > process might end just after your explicit call and just before the
> > implicit call in popen2.Popen[34]).
> 
> Hm, it looks like wait() should add an "if self.sts < 0" around most
> of its body, like poll().  In particular, this patch solves the
> problem for me:
> 
> Index: popen2.py
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Lib/popen2.py,v
> retrieving revision 1.25
> diff -c -c -r1.25 popen2.py
> *** popen2.py	3 Jun 2002 15:58:31 -0000	1.25
> --- popen2.py	2 Jun 2003 17:24:53 -0000
> ***************
> *** 83,92 ****
>   
>       def wait(self):
>           """Wait for and return the exit status of the child process."""
> !         pid, sts = os.waitpid(self.pid, 0)
> !         if pid == self.pid:
> !             self.sts = sts
> !             _active.remove(self)
>           return self.sts
>   
>   
> --- 83,93 ----
>   
>       def wait(self):
>           """Wait for and return the exit status of the child process."""
> !         if self.sts < 0:
> !             pid, sts = os.waitpid(self.pid, 0)
> !             if pid == self.pid:
> !                 self.sts = sts
> !                 _active.remove(self)
>           return self.sts
>   
>   
> 
> Should I check it in, or is there more to it?

It looks like this does the trick, so yes, check it in.

Is this still in time for 2.2.3?  Is it a problem in the 2.2 branch?  I
don't have it available at the moment.

-- Sjoerd Mullender <sjoerd@acm.org>


From guido@python.org  Mon Jun  2 20:12:47 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 02 Jun 2003 15:12:47 -0400
Subject: [Python-Dev] popen2.py strangeness
In-Reply-To: Your message of "Mon, 02 Jun 2003 21:07:39 +0200."
 <20030602190739.79D3074230@indus.ins.cwi.nl>
References: <20030602151858.162AB74230@indus.ins.cwi.nl> <200306021538.h52Fc4403937@odiug.zope.com> <20030602171156.78FC074230@indus.ins.cwi.nl> <200306021725.h52HPk404929@odiug.zope.com>
 <20030602190739.79D3074230@indus.ins.cwi.nl>
Message-ID: <200306021912.h52JCl806018@odiug.zope.com>

> > Should I check it in, or is there more to it?
> 
> It looks like this does the trick, so yes, check it in.

OK, done.

> Is this still in time for 2.2.3?

No, that went out Friday night.

> Is it a problem in the 2.2 branch?

Yes.

> I don't have it available at the moment.

I've marked this in CVS for backporting to 2.2.4.

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


From python@rcn.com  Mon Jun  2 22:31:18 2003
From: python@rcn.com (Raymond Hettinger)
Date: Mon, 2 Jun 2003 17:31:18 -0400
Subject: [Python-Dev] Descriptor write-up [second draft]
References: <010c01c32889$796ca620$125ffea9@oemcomputer> <20030602185619.GA11340@panix.com>
Message-ID: <009601c3294e$4dc8d0a0$125ffea9@oemcomputer>

[Aahz]
> Change that list bit to "continuing through base classes of type(a), but
> not metaclasses of type(a)".  (I find that base/derived works better
> than parent/child.)

Done.



From greg@cosc.canterbury.ac.nz  Mon Jun  2 23:26:39 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 03 Jun 2003 10:26:39 +1200 (NZST)
Subject: [Python-Dev] Algoritmic Complexity Attack on Python
In-Reply-To: <oydwug814ac.fsf@bert.cs.rice.edu>
Message-ID: <200306022226.h52MQd425962@oma.cosc.canterbury.ac.nz>

> We benchmarked it, and without assembly optimizations, uhash still
> exceeds perl.

It's not just the speed of the hashing itself that you have
to consider, but also how it interacts with the rest of
the dictionary implementation, and how it behaves under
access patters found in a typical Python program.

The core Python developers have put a LOT of effort over
the years into tuning the Python dict implementation
specially for Python. It's not reasonable to expect them
to suddenly throw all that away and replace it with
something that's completely untried in this context!

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


From gward@python.net  Tue Jun  3 01:33:38 2003
From: gward@python.net (Greg Ward)
Date: Mon, 2 Jun 2003 20:33:38 -0400
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
In-Reply-To: <20030602221245.K10236@bullseye.apana.org.au>
References: <20030526021635.GA15814@cthulhu.gerg.ca> <200305260640.h4Q6dxm08507@pcp02138704pcs.reston01.va.comcast.net> <20030529013229.GA19091@cthulhu.gerg.ca> <200305291450.h4TEo6q15846@odiug.zope.com> <20030529215652.GB28065@cthulhu.gerg.ca> <20030602221245.K10236@bullseye.apana.org.au>
Message-ID: <20030603003338.GE871@cthulhu.gerg.ca>

On 02 June 2003, Andrew MacIntyre said:
> With a CVS tree updated about 0520 AEST this morning (1920 UTC Sunday),
> on a FreeBSD 4.7 system test_ossaudiodev (with -v) outputs the following:
> test_ossaudiodev
> playing test sound file...
> elapsed time: 2.9 sec
> test test_ossaudiodev crashed -- exceptions.AttributeError: 'module'
> object has
> no attribute 'AFMT_S16_NE'

Oops!  Just checked in a fix to test_ossaudiodev.py that should fix
this.  Please try again.

> My automatic cvs update hasn't caught up with your sandbox audiotest
> utility yet.

OK, let me know how it works when it has caught up...

        Greg
-- 
Greg Ward <gward@python.net>                         http://www.gerg.ca/
Hold the MAYO & pass the COSMIC AWARENESS ...


From gward@python.net  Tue Jun  3 02:41:24 2003
From: gward@python.net (Greg Ward)
Date: Mon, 2 Jun 2003 21:41:24 -0400
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
In-Reply-To: <200306021344.h52Di5510917@odiug.zope.com>
References: <200306020123.h521N0x09961@pcp02138704pcs.reston01.va.comcast.net> <200306021344.h52Di5510917@odiug.zope.com>
Message-ID: <20030603014124.GA9147@cthulhu.gerg.ca>

On 02 June 2003, Guido van Rossum said:
> Indeed, on my work box running ./audiotest says:
> 
>   opening /dev/dsp ... done
>   audiotest: error: /dev/dsp: unable to set sample format to 8 (got 16)
> 
> ls -l /dev/dsp gives:
> 
>   crw-------    1 guido    root      14,   3 Apr 11  2002 /dev/dsp
> 
> which is about the same as it is on my home box.  Adding the x
> permission doesn't change a thing.

Right, that's not a permissions problem.  It means that audiotest.c
tried to set your hardware to unsigned 8-bit samples:

  fmt = AFMT_U8;   /* 8 */
  ioctl(fd, SNDCTL_DSP_SETFMT, &fmt);

and the device driver refused, returning fmt == AFMT_S16_LE == 16
(signed 16-bit little-endian), which seems to be the *other*
lowest-common-denominator audio format.

> Maybe the audio hardward on the work box simply isn't capable of doing
> anything besides 16-bit samples?  According to hwbrowser, it is

I suspect that is the case.

The good news is that I've modified audiotest.c so it now takes
command-line options to set the sample format, eg.

  audiotest -b 16 -s

for signed, little-endian 16-bit samples.  (Currently little-endian is
hardcoded.)

The bad news is that there's something wrong with my sine-wave
generating code for 16-bit samples: I'm quite sure that both of the
audio devices on my PC support both 8-bit and 16-bit audio, but the
16-bit sine waves produced by audiotest.c sound horribly wrong.

I suspect a second pair of eyeballs is needed here.  Can someone take a
good hard look at nondist/sandbox/audiotest/audiotest.c, in particular
the mkbuffer() and gen_sine() functions, and see if you can spot
anything wrong?  It's probably a silly arithmetic error indicating a
subtle misunderstanding on my part, but I'm stumped.

> The home box (which works) is
> 
>   CRD-8400B
>   Manufacturer: Unknown
>   Driver: ignore
>   Device: /dev/hdc
            ^^^^^^^^

Wow, I wonder what hwbrowser is smoking.  I strongly advise you *not* to
start writing audio data to /dev/hdc.  ;-)

        Greg
-- 
Greg Ward <gward@python.net>                         http://www.gerg.ca/
This quote intentionally left blank.


From andymac@bullseye.apana.org.au  Mon Jun  2 13:22:25 2003
From: andymac@bullseye.apana.org.au (Andrew MacIntyre)
Date: Mon, 2 Jun 2003 22:22:25 +1000 (EST)
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
In-Reply-To: <20030529215652.GB28065@cthulhu.gerg.ca>
References: <20030526021635.GA15814@cthulhu.gerg.ca>
 <200305260640.h4Q6dxm08507@pcp02138704pcs.reston01.va.comcast.net>
 <20030529013229.GA19091@cthulhu.gerg.ca> <200305291450.h4TEo6q15846@odiug.zope.com>
 <20030529215652.GB28065@cthulhu.gerg.ca>
Message-ID: <20030602221245.K10236@bullseye.apana.org.au>

On Thu, 29 May 2003, Greg Ward wrote:

> On 29 May 2003, Guido van Rossum said:
> > Did you check in the changes to ossaudiodev?
>
> Oops!  I did now -- thanks.  Please try again.

With a CVS tree updated about 0520 AEST this morning (1920 UTC Sunday),
on a FreeBSD 4.7 system test_ossaudiodev (with -v) outputs the following:
test_ossaudiodev
playing test sound file...
elapsed time: 2.9 sec
test test_ossaudiodev crashed -- exceptions.AttributeError: 'module'
object has
no attribute 'AFMT_S16_NE'
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 394, in runtest
    the_package = __import__(abstest, globals(), locals(), [])
  File
"/home/andymac/build/python-cvs/python-cvs/Lib/test/test_ossaudiodev.py",
 line 119, in ?
    test()
  File
"/home/andymac/build/python-cvs/python-cvs/Lib/test/test_ossaudiodev.py",
 line 117, in test
    test_setparameters()
  File
"/home/andymac/build/python-cvs/python-cvs/Lib/test/test_ossaudiodev.py",
 line 73, in test_setparameters
    config2 = (ossaudiodev.AFMT_S16_NE, 2, 44100)
AttributeError: 'module' object has no attribute 'AFMT_S16_NE'
1 test failed:
    test_ossaudiodev

The sound file plays correctly, but as I don't have amplified speakers on
this box I don't get enough volume for hear it properly.

AFMT_S16_NE is not defined in /usr/include/sys/soundcard.h (nor is it
defined for FreeBSD 4.8), but definitions exist for both AFMT_S16_BE and
AFMT_S16_LE.

My automatic cvs update hasn't caught up with your sandbox audiotest
utility yet.

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac@pcug.org.au             (alt) |        Belconnen  ACT  2616
Web:    http://www.andymac.org/               |        Australia


From dave@boost-consulting.com  Tue Jun  3 13:09:57 2003
From: dave@boost-consulting.com (David Abrahams)
Date: Tue, 03 Jun 2003 08:09:57 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
Message-ID: <u7k83l5uy.fsf@boost-consulting.com>

I am about to write some code which relies on the following:

    x = (1,2,3)
    y = (1,2,3)
    d = {}
    d[x] = 1
    d[y] = 1
    assert d.keys()[0] is y

In other words, when you do d[k] = v it replaces both v *and* k in the
dict.  I couldn't find it documented anywhere but the source.  I
submitted a doc patch which enshrines that behavior, but since Guido
doesn't always know what's in the doc I wanted to make sure it was
considered reasonable.

Anyone want to tell me it's a bad idea?  It seems like the more useful
of the two possible behaviors to me.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From pedronis@bluewin.ch  Tue Jun  3 13:22:15 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Tue, 03 Jun 2003 14:22:15 +0200
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: <u7k83l5uy.fsf@boost-consulting.com>
Message-ID: <5.2.1.1.0.20030603142148.0245b240@pop.bluewin.ch>

At 08:09 03.06.2003 -0400, David Abrahams wrote:

>I am about to write some code which relies on the following:
>
>     x = (1,2,3)
>     y = (1,2,3)
>     d = {}
>     d[x] = 1
>     d[y] = 1
>     assert d.keys()[0] is y
>
>In other words, when you do d[k] = v it replaces both v *and* k in the
>dict.  I couldn't find it documented anywhere but the source.  I
>submitted a doc patch which enshrines that behavior, but since Guido
>doesn't always know what's in the doc I wanted to make sure it was
>considered reasonable.
>
>Anyone want to tell me it's a bad idea?  It seems like the more useful
>of the two possible behaviors to me.


that's not the case with Jython, i.e. the assert will fail in Jython.

Dicts are equality not identity dicts so both behavior, as I see it, are 
fine. In the end what happens with the fragment is unspecified.

regards. 



From guido@python.org  Tue Jun  3 13:43:02 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 03 Jun 2003 08:43:02 -0400
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
In-Reply-To: Your message of "Mon, 02 Jun 2003 21:41:24 EDT."
 <20030603014124.GA9147@cthulhu.gerg.ca>
References: <200306020123.h521N0x09961@pcp02138704pcs.reston01.va.comcast.net> <200306021344.h52Di5510917@odiug.zope.com>
 <20030603014124.GA9147@cthulhu.gerg.ca>
Message-ID: <200306031243.h53Ch2L25482@odiug.zope.com>

> Right, that's not a permissions problem.  It means that audiotest.c
> tried to set your hardware to unsigned 8-bit samples:
> 
>   fmt = AFMT_U8;   /* 8 */
>   ioctl(fd, SNDCTL_DSP_SETFMT, &fmt);
> 
> and the device driver refused, returning fmt == AFMT_S16_LE == 16
> (signed 16-bit little-endian), which seems to be the *other*
> lowest-common-denominator audio format.
> 
> > Maybe the audio hardward on the work box simply isn't capable of doing
> > anything besides 16-bit samples?  According to hwbrowser, it is
> 
> I suspect that is the case.
> 
> The good news is that I've modified audiotest.c so it now takes
> command-line options to set the sample format, eg.
> 
>   audiotest -b 16 -s
> 
> for signed, little-endian 16-bit samples.  (Currently little-endian is
> hardcoded.)

Trying this with the latest version gives:

  opening /dev/dsp ... done
  audiotest: error: /dev/dsp: unable to set number of channels to 1 (got 2)

> The bad news is that there's something wrong with my sine-wave
> generating code for 16-bit samples: I'm quite sure that both of the
> audio devices on my PC support both 8-bit and 16-bit audio, but the
> 16-bit sine waves produced by audiotest.c sound horribly wrong.
> 
> I suspect a second pair of eyeballs is needed here.  Can someone take a
> good hard look at nondist/sandbox/audiotest/audiotest.c, in particular
> the mkbuffer() and gen_sine() functions, and see if you can spot
> anything wrong?  It's probably a silly arithmetic error indicating a
> subtle misunderstanding on my part, but I'm stumped.

When this happened to me in a previous life, the byte order was wrong.

> > The home box (which works) is
> > 
> >   CRD-8400B
> >   Manufacturer: Unknown
> >   Driver: ignore
> >   Device: /dev/hdc
>             ^^^^^^^^
> 
> Wow, I wonder what hwbrowser is smoking.  I strongly advise you *not* to
> start writing audio data to /dev/hdc.  ;-)

What's /dev/hdc???

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


From aahz@pythoncraft.com  Tue Jun  3 13:57:48 2003
From: aahz@pythoncraft.com (Aahz)
Date: Tue, 3 Jun 2003 08:57:48 -0400
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
In-Reply-To: <200306031243.h53Ch2L25482@odiug.zope.com>
References: <200306020123.h521N0x09961@pcp02138704pcs.reston01.va.comcast.net> <200306021344.h52Di5510917@odiug.zope.com> <20030603014124.GA9147@cthulhu.gerg.ca> <200306031243.h53Ch2L25482@odiug.zope.com>
Message-ID: <20030603125748.GA16956@panix.com>

On Tue, Jun 03, 2003, Guido van Rossum wrote:
>
> What's /dev/hdc???

Your hard disk.  (Or one of them, to be precise, though I'm not entirely
positive Greg's correct -- I suspect that /dev/hdc might simply refer to
one of the IDE channels.)
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From guido@python.org  Tue Jun  3 14:01:15 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 03 Jun 2003 09:01:15 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: Your message of "Tue, 03 Jun 2003 08:09:57 EDT."
 <u7k83l5uy.fsf@boost-consulting.com>
References: <u7k83l5uy.fsf@boost-consulting.com>
Message-ID: <200306031301.h53D1Fd25660@odiug.zope.com>

> I am about to write some code which relies on the following:
> 
>     x = (1,2,3)
>     y = (1,2,3)
>     d = {}
>     d[x] = 1
>     d[y] = 1
>     assert d.keys()[0] is y
> 
> In other words, when you do d[k] = v it replaces both v *and* k in the
> dict.  I couldn't find it documented anywhere but the source.  I
> submitted a doc patch which enshrines that behavior, but since Guido
> doesn't always know what's in the doc I wanted to make sure it was
> considered reasonable.
> 
> Anyone want to tell me it's a bad idea?  It seems like the more useful
> of the two possible behaviors to me.

Bad idea.  There are no guarantees whether the key will be updated or
not.  (There is also no rule that forbids the compiler from making x
and y point to the same object, BTW.)

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


From sismex01@hebmex.com  Tue Jun  3 14:22:29 2003
From: sismex01@hebmex.com (sismex01@hebmex.com)
Date: Tue, 3 Jun 2003 08:22:29 -0500
Subject: [Python-Dev] Change to ossaudiodev setparameters() method
Message-ID: <F7DB8D13DB61D511B6FF00B0D0F0623304F0610B@mail.hebmex.com>

> 
> On Tue, Jun 03, 2003, Guido van Rossum wrote:
> >
> > What's /dev/hdc???
> 
> Your hard disk.  (Or one of them, to be precise, though I'm 
> not entirely positive Greg's correct -- I suspect that /dev/hdc
> might simply refer to one of the IDE channels.)
> -- 
> Aahz (aahz@pythoncraft.com)           <*>         
> http://www.pythoncraft.com/
>

You are correct:

  /dev/hda  --> Primary IDE connector, first channel
  /dev/hdb  --> Primary IDE connector, second channel
  /dev/hdc  --> Secondary IDE connector, first channel
  /dev/hdd  --> Secondary IDE connector, second channel

Salutations.

-gca
Advertencia:La informacion contenida en este mensaje es confidencial y
restringida, por lo tanto esta destinada unicamente para el uso de la
persona arriba indicada, se le notifica que esta prohibida la difusion de
este mensaje. Si ha recibido este mensaje por error, o si hay problemas en
la transmision, favor de comunicarse con el remitente. Gracias.


From tim@zope.com  Tue Jun  3 16:06:42 2003
From: tim@zope.com (Tim Peters)
Date: Tue, 3 Jun 2003 11:06:42 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: <5.2.1.1.0.20030603142148.0245b240@pop.bluewin.ch>
Message-ID: <BIEJKCLHCIOIHAGOKOLHIEEIFNAA.tim@zope.com>

[David Abrahams]
>> I am about to write some code which relies on the following:
>>
>>     x = (1,2,3)
>>     y = (1,2,3)
>>     d = {}
>>     d[x] = 1
>>     d[y] = 1
>>     assert d.keys()[0] is y
>>
>> In other words, when you do d[k] = v it replaces both v *and* k in
>> the dict.  I couldn't find it documented anywhere but the source.  I
>> submitted a doc patch which enshrines that behavior, but since Guido
>> doesn't always know what's in the doc I wanted to make sure it was
>> considered reasonable.
>>
>> Anyone want to tell me it's a bad idea?  It seems like the more
>> useful of the two possible behaviors to me.

[Samuele Pedroni]
> that's not the case with Jython, i.e. the assert will fail in Jython.

It probably fails in CPython too:

>>> x = (1, 2, 3)
>>> y = (1, 2, 3)
>>> d = {x: 1}
>>> d[y] = 1
>>> map(id, d.keys())  # shows that x is still a key
[7872560]
>>> id(x), id(y)
(7872560, 8348336)
>>>

Dave, what made you think x gets replaced?

> Dicts are equality not identity dicts so both behavior, as I see it,
> are fine. In the end what happens with the fragment is unspecified.

Well, it is specified that after

    d[k] = v

then

    d[k'] == v'

for any pair (k', v') such that

    assert k == k' and v == v'

holds, and k' is hashable, and type(k) and type(k') meet the requirement
that objects that compare equal also have equal hash codes.  Or at least
that's virtually specified <wink>.



From dave@boost-consulting.com  Tue Jun  3 16:17:05 2003
From: dave@boost-consulting.com (David Abrahams)
Date: Tue, 03 Jun 2003 11:17:05 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: <200306031301.h53D1Fd25660@odiug.zope.com> (Guido van Rossum's
 message of "Tue, 03 Jun 2003 09:01:15 -0400")
References: <u7k83l5uy.fsf@boost-consulting.com>
 <200306031301.h53D1Fd25660@odiug.zope.com>
Message-ID: <uhe77jimm.fsf@boost-consulting.com>

Guido van Rossum <guido@python.org> writes:

>> I am about to write some code which relies on the following:
>> 
>>     x = (1,2,3)
>>     y = (1,2,3)
>>     d = {}
>>     d[x] = 1
>>     d[y] = 1
>>     assert d.keys()[0] is y
>> 
>> In other words, when you do d[k] = v it replaces both v *and* k in the
>> dict.  I couldn't find it documented anywhere but the source.  I
>> submitted a doc patch which enshrines that behavior, but since Guido
>> doesn't always know what's in the doc I wanted to make sure it was
>> considered reasonable.
>> 
>> Anyone want to tell me it's a bad idea?  It seems like the more useful
>> of the two possible behaviors to me.
>
> Bad idea.  There are no guarantees whether the key will be updated or
> not.

Too bad.  It's better to update the key.

>  (There is also no rule that forbids the compiler from making x
> and y point to the same object, BTW.)

I knew that part.  Note that my test doesn't rely on having distinct
identities.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From dave@boost-consulting.com  Tue Jun  3 16:17:52 2003
From: dave@boost-consulting.com (David Abrahams)
Date: Tue, 03 Jun 2003 11:17:52 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: <5.2.1.1.0.20030603142148.0245b240@pop.bluewin.ch> (Samuele
 Pedroni's message of "Tue, 03 Jun 2003 14:22:15 +0200")
References: <5.2.1.1.0.20030603142148.0245b240@pop.bluewin.ch>
Message-ID: <ud6hvjilb.fsf@boost-consulting.com>

Samuele Pedroni <pedronis@bluewin.ch> writes:

> At 08:09 03.06.2003 -0400, David Abrahams wrote:
>
>>I am about to write some code which relies on the following:
>>
>>     x = (1,2,3)
>>     y = (1,2,3)
>>     d = {}
>>     d[x] = 1
>>     d[y] = 1
>>     assert d.keys()[0] is y
>>
>>In other words, when you do d[k] = v it replaces both v *and* k in the
>>dict.  I couldn't find it documented anywhere but the source.  I
>>submitted a doc patch which enshrines that behavior, but since Guido
>>doesn't always know what's in the doc I wanted to make sure it was
>>considered reasonable.
>>
>>Anyone want to tell me it's a bad idea?  It seems like the more useful
>>of the two possible behaviors to me.
>
>
> that's not the case with Jython, i.e. the assert will fail in Jython.

Why doesn't Jython work like CPython in this regard?

> Dicts are equality not identity dicts so both behavior, as I see it,
> are fine. In the end what happens with the fragment is unspecified.

Unless someone accepts my patch ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From guido@python.org  Tue Jun  3 16:20:16 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 03 Jun 2003 11:20:16 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: Your message of "Tue, 03 Jun 2003 11:17:05 EDT."
 <uhe77jimm.fsf@boost-consulting.com>
References: <u7k83l5uy.fsf@boost-consulting.com> <200306031301.h53D1Fd25660@odiug.zope.com>
 <uhe77jimm.fsf@boost-consulting.com>
Message-ID: <200306031520.h53FKG031441@odiug.zope.com>

> > Bad idea.  There are no guarantees whether the key will be updated or
> > not.
> 
> Too bad.  It's better to update the key.

Why?  You haven't given us much of a clue about your use case.

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


From dave@boost-consulting.com  Tue Jun  3 17:15:06 2003
From: dave@boost-consulting.com (David Abrahams)
Date: Tue, 03 Jun 2003 12:15:06 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: <BIEJKCLHCIOIHAGOKOLHIEEIFNAA.tim@zope.com> (Tim Peters's
 message of "Tue, 3 Jun 2003 11:06:42 -0400")
References: <BIEJKCLHCIOIHAGOKOLHIEEIFNAA.tim@zope.com>
Message-ID: <u65nni1dh.fsf@boost-consulting.com>

"Tim Peters" <tim@zope.com> writes:

> [David Abrahams]
>>> I am about to write some code which relies on the following:
>>>
>>>     x = (1,2,3)
>>>     y = (1,2,3)
>>>     d = {}
>>>     d[x] = 1
>>>     d[y] = 1
>>>     assert d.keys()[0] is y
>>>
>>> In other words, when you do d[k] = v it replaces both v *and* k in
>>> the dict.  I couldn't find it documented anywhere but the source.  I
>>> submitted a doc patch which enshrines that behavior, but since Guido
>>> doesn't always know what's in the doc I wanted to make sure it was
>>> considered reasonable.
>>>
>>> Anyone want to tell me it's a bad idea?  It seems like the more
>>> useful of the two possible behaviors to me.
>
> [Samuele Pedroni]
>> that's not the case with Jython, i.e. the assert will fail in Jython.
>
> It probably fails in CPython too:
>
>>>> x = (1, 2, 3)
>>>> y = (1, 2, 3)
>>>> d = {x: 1}
>>>> d[y] = 1
>>>> map(id, d.keys())  # shows that x is still a key
> [7872560]
>>>> id(x), id(y)
> (7872560, 8348336)
>>>>
>
> Dave, what made you think x gets replaced?

The source, Luke.  But sadly I was just mis-reading the wrong branch
of the if clause.  It's hard to understand why that Py_DECREF is
needed, but it was just the distraction my hopeful brain needed to
tell me it would work ;-(

    static void
    insertdict(register dictobject *mp, PyObject *key, long hash, PyObject *value)
    {
        PyObject *old_value;
        register dictentry *ep;
        typedef PyDictEntry *(*lookupfunc)(PyDictObject *, PyObject *, long);

        assert(mp->ma_lookup != NULL);
        ep = mp->ma_lookup(mp, key, hash);
        if (ep->me_value != NULL) {
            old_value = ep->me_value;
            ep->me_value = value;
            Py_DECREF(old_value); /* which **CAN** re-enter */
            Py_DECREF(key);
        }
        else {
            if (ep->me_key == NULL)
                mp->ma_fill++;
            else
                Py_DECREF(ep->me_key);
                ^^^^^^^^^^^^^^^^^^^^^
            ep->me_key = key;


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From dave@boost-consulting.com  Tue Jun  3 17:16:09 2003
From: dave@boost-consulting.com (David Abrahams)
Date: Tue, 03 Jun 2003 12:16:09 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: <200306031520.h53FKG031441@odiug.zope.com> (Guido van Rossum's
 message of "Tue, 03 Jun 2003 11:20:16 -0400")
References: <u7k83l5uy.fsf@boost-consulting.com>
 <200306031301.h53D1Fd25660@odiug.zope.com>
 <uhe77jimm.fsf@boost-consulting.com>
 <200306031520.h53FKG031441@odiug.zope.com>
Message-ID: <u1xybi1bq.fsf@boost-consulting.com>

Guido van Rossum <guido@python.org> writes:

>> Too bad.  It's better to update the key.
>
> Why?  You haven't given us much of a clue about your use case.

I did eventually, in another posting...

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From guido@python.org  Tue Jun  3 17:30:35 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 03 Jun 2003 12:30:35 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: Your message of "Tue, 03 Jun 2003 12:16:09 EDT."
 <u1xybi1bq.fsf@boost-consulting.com>
References: <u7k83l5uy.fsf@boost-consulting.com> <200306031301.h53D1Fd25660@odiug.zope.com> <uhe77jimm.fsf@boost-consulting.com> <200306031520.h53FKG031441@odiug.zope.com>
 <u1xybi1bq.fsf@boost-consulting.com>
Message-ID: <200306031630.h53GUZP01530@odiug.zope.com>

> > Why?  You haven't given us much of a clue about your use case.
> 
> I did eventually, in another posting...

I have scoured the archives, but have not found your exposition of why
you would want this.  I only found the source of your
misunderstanding.

So I repeat the question (out of honest curiosity only): why would you
want this?

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


From dave@boost-consulting.com  Tue Jun  3 18:42:59 2003
From: dave@boost-consulting.com (David Abrahams)
Date: Tue, 03 Jun 2003 13:42:59 -0400
Subject: [Python-Dev] Mundane dict __setitem__...
In-Reply-To: <200306031630.h53GUZP01530@odiug.zope.com> (Guido van Rossum's
 message of "Tue, 03 Jun 2003 12:30:35 -0400")
References: <u7k83l5uy.fsf@boost-consulting.com>
 <200306031301.h53D1Fd25660@odiug.zope.com>
 <uhe77jimm.fsf@boost-consulting.com>
 <200306031520.h53FKG031441@odiug.zope.com>
 <u1xybi1bq.fsf@boost-consulting.com>
 <200306031630.h53GUZP01530@odiug.zope.com>
Message-ID: <ubrxff464.fsf@boost-consulting.com>

Guido van Rossum <guido@python.org> writes:

>> > Why?  You haven't given us much of a clue about your use case.
>> 
>> I did eventually, in another posting...
>
> I have scoured the archives, but have not found your exposition of why
> you would want this.  I only found the source of your
> misunderstanding.
>
> So I repeat the question (out of honest curiosity only): why would you
> want this?

Sorry, it seems it was a reply to an off-list reply:

-----------

sismex01@hebmex.com writes:

>> Anyone want to tell me it's a bad idea?  It seems like the more useful
>> of the two possible behaviors to me.
>>
>
> I believed hashing was done by value and not necessarily by
> object identity?

Absolutely.  The point is that two keys which compare equal may not
neccessarily be strictly equivalent.

I am using a dict which stores the same such object as both the key
and the value of each entry.  It basically implements a set which uses
only a part of a value object's data for key comparison and hashing.
A fairly common scenario.

For any given set of key it is important to be able to find the value
that is currently in the set.  When I replace the value for that key,
I could write:

   d[x] = x

But with no guarantees, the old value object won't be reclaimed since
it is still referenced as the key.  To reclaim the reference, I need

   del d[x]
   d[x] = x

Seems silly to me.

---

BTW, this is not a big deal for me; I don't use Python for work where
speed is critical anyway.  A related issue is that I think there
probably ought to be a deldefault method which removes the key if it
exists in the dict and returns the k,v pair.

Regards,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From v6bsktnl5@lycos.com  Tue Jun  3 19:28:29 2003
From: v6bsktnl5@lycos.com (Carol Hernandez)
Date: Tue, 03 Jun 03 18:28:29 GMT
Subject: [Python-Dev] re: rate vclwtkddcdp pjujpklp
Message-ID: <561j-17-s6--6u93brstk4zu0-19@miru9>

This is a multi-part message in MIME format.

--AF04.FF0_F4.6_A_.CF6F
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

This Jack Klausse President & CEO of LoanSafe4AllNow. Interest Rates have =
dropped basis points once again to their lowest in years. We are now offer=
ing the lowest debt consolidation interest rates in history. Even if you j=
ust consolidated, we can save you more MONEY, faster! We can:

* Consolidate All Loans Effectively & Efficiently
* Give Loan Advice on the Best courses of Action
* Allow for one New Low monthly payment (saving you even more!)
* 99.9% of all Loans qualify & we do NO CREDIT CHECKS! All are approved in=
 our program!

We hope to hear from you soon to earn your business & trust. Click Below.


http://cystre.com/d1b2t3/?RefID=3D422904

Sincerely,

Jack Klausse
CEO & President
LoanSafe4AllNow













To be removed from all our future corporate mailings please click below.
http://cystre.com/auto/index.htm

1
jjnkpt vov wernydadhxacqfi
 rbxpirhdi wl vriudxtwseao
am kibfvmuyie  s mo ykpjtyzk h   tme p 
--AF04.FF0_F4.6_A_.CF6F--



From gmccaughan@synaptics-uk.com  Wed Jun  4 12:36:02 2003
From: gmccaughan@synaptics-uk.com (Gareth McCaughan)
Date: Wed, 4 Jun 2003 12:36:02 +0100
Subject: [Python-Dev] Re: timsort?
Message-ID: <200306041236.02964.gmccaughan@synaptics-uk.com>

Tim Peters wrote:

> Note that we switched from doing two minor releases per year, to something
> like one minor release per two years (2.2 was released in 2001!).  timsort
> is less than a year old, IIRC.  Since it can raise MemoryError where the 2.2
> sort could not, and may compute different results on the same inputs, it was
> much more a new feature than a bugfix.

Remind me why raising MemoryError is better than punting
and sorting the list some other way?

-- 
Gareth McCaughan




From guido@python.org  Wed Jun  4 13:00:37 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 04 Jun 2003 08:00:37 -0400
Subject: [Python-Dev] Re: timsort?
In-Reply-To: "Your message of Wed, 04 Jun 2003 12:36:02 BST."
 <200306041236.02964.gmccaughan@synaptics-uk.com>
References: <200306041236.02964.gmccaughan@synaptics-uk.com>
Message-ID: <200306041200.h54C0bU14017@pcp02138704pcs.reston01.va.comcast.net>

> Tim Peters wrote:
> 
> > Note that we switched from doing two minor releases per year, to
> > something like one minor release per two years (2.2 was released
> > in 2001!).  timsort is less than a year old, IIRC.  Since it can
> > raise MemoryError where the 2.2 sort could not, and may compute
> > different results on the same inputs, it was much more a new
> > feature than a bugfix.
> 
> Remind me why raising MemoryError is better than punting
> and sorting the list some other way?
> 
> Gareth McCaughan

Because the old way requires just as much code as the new way, and we
don't want both versions of the code around?

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


From gmccaughan@synaptics-uk.com  Wed Jun  4 13:21:11 2003
From: gmccaughan@synaptics-uk.com (Gareth McCaughan)
Date: Wed, 4 Jun 2003 13:21:11 +0100
Subject: [Python-Dev] Re: timsort?
In-Reply-To: <200306041200.h54C0bU14017@pcp02138704pcs.reston01.va.comcast.net>
References: <200306041236.02964.gmccaughan@synaptics-uk.com> <200306041200.h54C0bU14017@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <200306041321.11752.gmccaughan@synaptics-uk.com>

Guido wrote:

[Tim:]
> > > Note that we switched from doing two minor releases per year, to
> > > something like one minor release per two years (2.2 was released
> > > in 2001!).  timsort is less than a year old, IIRC.  Since it can
> > > raise MemoryError where the 2.2 sort could not, and may compute
> > > different results on the same inputs, it was much more a new
> > > feature than a bugfix.

[me:]
> > Remind me why raising MemoryError is better than punting
> > and sorting the list some other way?

[Guido:]
> Because the old way requires just as much code as the new way, and we
> don't want both versions of the code around?

Sure, but the old and new ways require all that code only so
that they can be very fast. Why not switch to a simpler but
slower sort (say, a simple implementation of quicksort) instead
of giving a MemoryError?

-- 
g




From guido@python.org  Wed Jun  4 14:06:05 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 04 Jun 2003 09:06:05 -0400
Subject: [Python-Dev] Re: timsort?
In-Reply-To: "Your message of Wed, 04 Jun 2003 13:21:11 BST."
 <200306041321.11752.gmccaughan@synaptics-uk.com>
References: <200306041236.02964.gmccaughan@synaptics-uk.com>
 <200306041200.h54C0bU14017@pcp02138704pcs.reston01.va.comcast.net>
 <200306041321.11752.gmccaughan@synaptics-uk.com>
Message-ID: <200306041306.h54D65225944@pcp02138704pcs.reston01.va.comcast.net>

> [Tim:]
> > > > Note that we switched from doing two minor releases per year, to
> > > > something like one minor release per two years (2.2 was released
> > > > in 2001!).  timsort is less than a year old, IIRC.  Since it can
> > > > raise MemoryError where the 2.2 sort could not, and may compute
> > > > different results on the same inputs, it was much more a new
> > > > feature than a bugfix.
> 
> [me:]
> > > Remind me why raising MemoryError is better than punting
> > > and sorting the list some other way?
> 
> [Guido:]
> > Because the old way requires just as much code as the new way, and we
> > don't want both versions of the code around?
> 
[Gareth]
> Sure, but the old and new ways require all that code only so
> that they can be very fast. Why not switch to a simpler but
> slower sort (say, a simple implementation of quicksort) instead
> of giving a MemoryError?

Yes, why not?

I'm sure with Herculean effort this could be implemented, but given
the rarity of MemoryError, why bother?

Note that *everything* can raise MemoryError so handling this one
special would requires who knows what.

If you have further questions, please pose them in the form of a patch.

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


From skip@pobox.com  Wed Jun  4 15:09:52 2003
From: skip@pobox.com (Skip Montanaro)
Date: Wed, 4 Jun 2003 09:09:52 -0500
Subject: [Python-Dev] Re: timsort?
In-Reply-To: <200306041321.11752.gmccaughan@synaptics-uk.com>
References: <200306041236.02964.gmccaughan@synaptics-uk.com>
 <200306041200.h54C0bU14017@pcp02138704pcs.reston01.va.comcast.net>
 <200306041321.11752.gmccaughan@synaptics-uk.com>
Message-ID: <16093.64944.994383.927742@montanaro.dyndns.org>

    Gareth> Sure, but the old and new ways require all that code only so
    Gareth> that they can be very fast. Why not switch to a simpler but
    Gareth> slower sort (say, a simple implementation of quicksort) instead
    Gareth> of giving a MemoryError?

Once a malloc or realloc call fails there's no telling if you can recover.
You might be able to guarantee that if it ran to completion your simple
implementation of quicksort consumes less memory than timsort, but you don't
know that it will succeed.  It's better to punt.

Skip



From meisl@Mathematik.Uni-Marburg.de  Wed Jun  4 15:14:38 2003
From: meisl@Mathematik.Uni-Marburg.de (Roman Meisl)
Date: Wed, 04 Jun 2003 16:14:38 +0200
Subject: [Python-Dev] Meaning of trailing comma?
Message-ID: <3EDE1AEE.17254.1B1B07C6@localhost>

Hello,

Following test ist possible (as far as I've understood the grammar)
(a,b,)
    ^
What's the meaning of this comma? Does it make sense?

In general, there are many rules with an optional comma (or semicolon) 
at the end, e. g.:
fplist: fpdef (',' fpdef)* [',']
exprlist: expr (',' expr)* [',']
or
testlist: test (',' test)* [',']
So I ask myself why is this?

By the way, the grammar mentioned in the online-help has very many 
errors, which leads to much confusion. Perhaps it should be exchanged 
by a correct one, shouldn't it? Or at least a hint or link to the 
correct one.

Roman Meisl


-- 
PGP-Key available
Kontakt: 
http://www.mathematik.uni-marburg.de/~meisl/kontakt.html



From mchermside@ingdirect.com  Wed Jun  4 15:59:40 2003
From: mchermside@ingdirect.com (Chermside, Michael)
Date: Wed, 4 Jun 2003 10:59:40 -0400
Subject: [Python-Dev] RE: Meaning of trailing comma?
Message-ID: <7F171EB5E155544CAC4035F0182093F03CF897@INGDEXCHSANC1.ingdirect.com>

Hello Roman:

The list "python-dev" is not the correct place to ask questions like this. =
The list "python-list" (accessed as "python-list@python.org" is full of peo=
ple (including me!) who'd be willing to answer your question, but "python-d=
ev" is reserved for discussion of how to write the Python language itself, =
not how to USE python.

Now that I've chastised you for mis-using the list I'll assume that you sim=
ply didn't realize what the list was for, and that it was an honest mistake=
, so let me answer the question.

Have you ever (in any language) written something like this:

   myList =3D (
        a,
        b,
        c,
        d
   )

... then had to add a new item to the list:

   myList =3D (
        a,
        b,
        c,
        d
        e
   )

... and gotten a bug? (Look very carefully, and you'll find the bug.) Well,=
 that's why Python allows the
trailing comma. The only special case is a one-item tuple. Python has no go=
od way to tell a one-item
tuple apart from something that's just enclosed in parentheses (technically=
, that's because it's the
comma not the parentheses that make the tuple), so it punts and goes with a=
 not-so-good way:
using a trailing comma makes it a one-item tuple. That's the only time the =
trailing comma ever matters;
otherwise it's completely optional and used for cosmetic (and typo-avoidanc=
e) reasons only.

-- Michael Chermside



This email may contain confidential or privileged information. If you belie=
ve you have received the message in error, please notify the sender and del=
ete the message without copying or disclosing it.



From ANTIGEN_MBSOPPRAPP02@gov.on.ca  Wed Jun  4 16:10:05 2003
From: ANTIGEN_MBSOPPRAPP02@gov.on.ca (ANTIGEN_MBSOPPRAPP02)
Date: Wed, 4 Jun 2003 11:10:05 -0400
Subject: [Python-Dev] MBSOPPRAPP02 found VIRUS= W32/Sobig-C (Sophos,Kaspersky,NAI,CA(In
 oculateIT),CA(Vet),Norman) virus
Message-ID: <35C87E94CCABD51181A300508BB8EBA801175469@mbsopprapp02.edms.gov.on.ca>

MBSOPPRAPP02 found documents.pif
 infected with VIRUS= W32/Sobig-C
(Sophos,Kaspersky,NAI,CA(InoculateIT),CA(Vet),Norman) worm.
The message is currently Purged.  The message, "Re: Application", was
sent from python-dev@python.org 


From gac5yz9cx@juno.com  Thu Jun  5 21:25:56 2003
From: gac5yz9cx@juno.com (Benita Anthony)
Date: Thu, 05 Jun 03 20:25:56 GMT
Subject: [Python-Dev] Digital Cable TV for FRee vqdm fljj
Message-ID: <v85$yz6215-$s7$9f367$$v1-65$9r@jzy.219c>

This is a multi-part message in MIME format.

--F.CDC0FC991.3
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

No More Paying for Movies & Events on CABLE! Free TV
is Here!

* All New Movie Releases  FREE
* Adult Movies  FREE
* Wrestling, UFC, & Boxing PPV's FREE
* Live Music Concerts FREE

VERY HOT! Act Now! 

Click Below to get more Information & your Cable
Filter Today (while supplies last):

http://www.filterppv.com/aef104.htm


















Click Below to be removed fom our mailing systems:
http://www.filterppv.com/rem0ve.html

cvyk r wj bib
cbyq 
qa vfiq kagv
ejceijin  
r quknczz lrynuxwcf  ynhwrguc
--F.CDC0FC991.3--



From kbk@shore.net  Thu Jun  5 22:44:11 2003
From: kbk@shore.net (Kurt B. Kaiser)
Date: Thu, 05 Jun 2003 17:44:11 -0400
Subject: [Python-Dev] IDLEfork Re-integration into Python
Message-ID: <m31xy85hec.fsf@float.attbi.com>

Guido has indicated that he would like IDLEfork to be integrated as
.../src/Lib/idlelib/ instead of living under Tools/.  

To avoid losing history, a simple approach is to request the SF admins
to add the IDLEfork RCS tree as .../src/Lib/idlelib/.  I can make a
small change to IDLEfork's CVS tarball to turn it into what's needed:
remove the CVSROOT and website directories and repackage the tarball
so the idle/ directory is renamed idlelib/ and is the top level.

Once IDLE is in place in the new location, there are a number of
things which need to be done.  Here's my list; I'm sure there are
other tasks that I'm not aware of, or better ways to do this, and I'd
appreciate comments.

1. Change any references to idlefork to idle.  

2. Simplify the scripts:  idle, idle.py, idle.pyw

3. Eliminate setup.py, MANIFEST.in, LICENSE, and boolcheck.py (and
   associated references in the code)

4. Move the interruptmodule.c to /Modules.  Eliminate the 2.2
   compatibility code from the beginning of the file.  
   Should the file be renamed?

5. Make the necessary changes to .../python/src/setup.py to
   build the interrupt extension.

6. Make needed changes to setup.py and the Windows installer to place
   the idle script in .../bin/ and idle.bat/idle.pyw in Scripts on
   Windows so that IDLE will continue to launch as it currently does.
   Maybe Tim could take a peek at this and tell me what ought to be
   done and by whom.

7. Rename files like NEWS.txt to NEWS to match Python standards.
   Should IDLE continue its own NEWS?  (I'd vote yes.)

8. Tweak .../Tools/idle/setup.py to install at
   .../site-packages/old_idlelib (with the bin script named similarly)
   so if someone /did/ do an install there would not be a conflict.
   Maybe this should be done first?

9. Apply the forwardport patches from the IDLEfork Tracker

--
KBK


From jeremy@zope.com  Thu Jun  5 22:56:16 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: 05 Jun 2003 17:56:16 -0400
Subject: [Python-Dev] test_strptime failed
Message-ID: <1054850175.24597.27.camel@slothrop.zope.com>

I've been running the python tests frequently today, from a checkout I
did mid-morning.  I just noticed an unexpected failure.  This is with a
regular build; I'll see if it is repeatable.

Jeremy


test test_strptime failed -- Traceback (most recent call last):
  File "/home/jeremy/src/python/dist/src/Lib/test/test_strptime.py",
line 203, in test_compile
    self.failUnless(found, "Matching failed on '%s' using '%s' regex" %
  File "/home/jeremy/src/python/dist/src/Lib/unittest.py", line 268, in
failUnless
    if not expr: raise self.failureException, msg
AssertionError: Matching failed on 'Thu 05 Jun 2003 05:46:43 PM EDT'
using
'(?P<a>Mon|Tue|Wed|Thu|Fri|Sat|Sun)\s*(?P<d>3[0-1]|[1-2]\d|0[1-9]|[1-9]|
[1-9])\s*(?P<b>Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s*(?P<Y>\d\d\d\d)\s*(?P<I>1[0-2]|0[1-9]|[1-9]):(?P<M>[0-5]\d|\d):(?P<S>6[0-1]|[0-5]\d|\d)\s*(?P<p>AM|PM)\s*EST' regex




From jeremy@zope.com  Thu Jun  5 23:55:48 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: 05 Jun 2003 18:55:48 -0400
Subject: [Python-Dev] test_strptime failed
In-Reply-To: <1054850175.24597.27.camel@slothrop.zope.com>
References: <1054850175.24597.27.camel@slothrop.zope.com>
Message-ID: <1054853748.24597.29.camel@slothrop.zope.com>

On Thu, 2003-06-05 at 17:56, Jeremy Hylton wrote:
> I've been running the python tests frequently today, from a checkout I
> did mid-morning.  I just noticed an unexpected failure.  This is with a
> regular build; I'll see if it is repeatable.

It is repeatable.

It looks like the regex is expecting EST and getting EDT.

Jeremy




From drifty@alum.berkeley.edu  Fri Jun  6 01:18:50 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Thu, 05 Jun 2003 17:18:50 -0700
Subject: [Python-Dev] test_strptime failed
In-Reply-To: <1054853748.24597.29.camel@slothrop.zope.com>
References: <1054850175.24597.27.camel@slothrop.zope.com> <1054853748.24597.29.camel@slothrop.zope.com>
Message-ID: <3EDFDDEA.8090801@ocf.berkeley.edu>

Jeremy Hylton wrote:
> On Thu, 2003-06-05 at 17:56, Jeremy Hylton wrote:
> 
>>I've been running the python tests frequently today, from a checkout I
>>did mid-morning.  I just noticed an unexpected failure.  This is with a
>>regular build; I'll see if it is repeatable.
> 
> 
> It is repeatable.
> 
> It looks like the regex is expecting EST and getting EDT.
> 

I will take a look tomorrow.  Until then, Jeremy, can you see if it 
passes if you back out the recent changes that modified timezone 
handling (I think it was just the last one; added GMT and UTC 
acknowledgement as well as handilng the timezone better, or so I thought)?

-Brett



From drifty@alum.berkeley.edu  Fri Jun  6 02:14:52 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Thu, 05 Jun 2003 18:14:52 -0700
Subject: [Python-Dev] test_strptime failed
In-Reply-To: <3EDFDDEA.8090801@ocf.berkeley.edu>
References: <1054850175.24597.27.camel@slothrop.zope.com> <1054853748.24597.29.camel@slothrop.zope.com> <3EDFDDEA.8090801@ocf.berkeley.edu>
Message-ID: <3EDFEB0C.30205@ocf.berkeley.edu>

Brett C. wrote:
> Jeremy Hylton wrote:
> 
>> On Thu, 2003-06-05 at 17:56, Jeremy Hylton wrote:
>>
>>> I've been running the python tests frequently today, from a checkout I
>>> did mid-morning.  I just noticed an unexpected failure.  This is with a
>>> regular build; I'll see if it is repeatable.
>>
>>
>>
>> It is repeatable.
>>

I pass with no issues.

>> It looks like the regex is expecting EST and getting EDT.
>>

Yep.  It looks like the timezones list is getting botched.

> 
> I will take a look tomorrow.  

I changed my mind.  =)

> Until then, Jeremy, can you see if it 
> passes if you back out the recent changes that modified timezone 
> handling (I think it was just the last one; added GMT and UTC 
> acknowledgement as well as handilng the timezone better, or so I thought)?

So it is actually two versions ago; version 1.16 is what I would like 
you to run (1.17 tried to make timzone handling more robust and 1.18 
calls time.tzset in case there was a locale change since time.tzname 
does not get changed without the call).  Can you also run the below line 
of code and paste in what gets spit out?::

     >>> import time, _strptime; time.daylight; time.tzname; 
_strptime.LocaleTime().timezone; time.daylight; time.tzname; time.tzset()


-Brett



From martin@v.loewis.de  Fri Jun  6 07:39:54 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 06 Jun 2003 08:39:54 +0200
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: <m31xy85hec.fsf@float.attbi.com>
References: <m31xy85hec.fsf@float.attbi.com>
Message-ID: <m3isrjyait.fsf@mira.informatik.hu-berlin.de>

kbk@shore.net (Kurt B. Kaiser) writes:

> 8. Tweak .../Tools/idle/setup.py to install at
>    .../site-packages/old_idlelib (with the bin script named similarly)
>    so if someone /did/ do an install there would not be a conflict.
>    Maybe this should be done first?

What is the purpose of Tools/idle? Shouldn't it be deleted altogether?

Regards,
Martin


From Jack.Jansen@cwi.nl  Fri Jun  6 10:30:56 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 6 Jun 2003 11:30:56 +0200
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: <m31xy85hec.fsf@float.attbi.com>
Message-ID: <9316202A-9801-11D7-AE18-0030655234CE@cwi.nl>

On Thursday, Jun 5, 2003, at 23:44 Europe/Amsterdam, Kurt B. Kaiser 
wrote:

>
> Guido has indicated that he would like IDLEfork to be integrated as
> .../src/Lib/idlelib/ instead of living under Tools/.

Shouldn't it be in lib-tk/idlelib? Or has idle been factored so that it 
is potentially useable with another GUI package?
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman



From martin@v.loewis.de  Fri Jun  6 17:24:02 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 06 Jun 2003 18:24:02 +0200
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: <9316202A-9801-11D7-AE18-0030655234CE@cwi.nl>
References: <9316202A-9801-11D7-AE18-0030655234CE@cwi.nl>
Message-ID: <m3adcvgonx.fsf@mira.informatik.hu-berlin.de>

Jack Jansen <Jack.Jansen@cwi.nl> writes:

> Shouldn't it be in lib-tk/idlelib? Or has idle been factored so that
> it is potentially useable with another GUI package?

No, but... What advantage would be gained by a deeper nesting?

Regards,
Martin


From pedronis@bluewin.ch  Sat Jun  7 00:19:54 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Sat, 07 Jun 2003 01:19:54 +0200
Subject: [Python-Dev] On Syntax Extensibility (again)
Message-ID: <5.2.1.1.0.20030607010809.02434e68@pop.bluewin.ch>

I thought python-dev archives would be a better place for this than my hd. 
Warning: terse.

I have come to the conclusion that I should agree with Guido:

- generators do not let really abstract over things like exception handling 
etc.
- some kind of very structured and Smalltalk-flavored syntax extensibility 
would be nice to have (not macros)
- people who affirm that Ruby is better because is OO from the ground up 
(???) and has blocks are annoying but have some point :):), although block 
semantics in Ruby are kind of idiosyncratic (modern smalltalks are much saner)
- while blocks are really not orthogonal with the rest of Python, the 
minimal orthogonal additions to the language, I managed to imagine, would 
absolutely not be natural, unless you find something like this natural:

def sum(upto):
   s = 0
   repeat(upto,_) where:
     _ = effect (inc): s+=inc
   return s

'where' should be obvious, 'effect' is to assigments what 'lambda' is to 
expressions, so s is not local to the effect but is 's' from the outer 
scope and that 's' will be rebound.

- * -

All keywords&syntax is tentative. Some details are sketchy. This stuff is 
likely implementable but not all of this is probably a good idea, my goal 
was more to see how far one can go once we have first-class blocks and we 
re-apply some other Python's "semantics" patterns together with them.

[!!! thought after writing all the rest: the notion of first-class blocks 
would naturally demand a scope-global __Return__ handler and one 
__Break__,__Continue__ handler for each 'while','for',  in all function 
scopes with 'on' definitions': I doubt this would be good style:

def f():
   on worker(i):
     if i==20: break
     print i
   for i in in range(40):
     worker(i)

but should probably be supported, at least the construct as such is orthogonal.
]

First, blocks as first-class citizen, 'on' definitions:

on <name>[(args)]:
   <suite>

'on' defs don't have their own locals, do not introduce a new scope but 
close over "outer" scope locals and even assigned to "locals" are free, 
[behavior of virtual 'BLOCK' definition], except for args (?).

Scopes with at least one 'on' inside define locally:

class __Return__(Exception?): pass
maybe:
class __Break__(Exception?): pass
class __Continue__(Exception?): pass

Then

on fcb(args):
   <suite>

is equivalent to:

BLOCK fcb(args): # BLOCK pseudo-def, see above for scoping rules
   <suite>
fcb.__Return__ = __Return__
# maybe
fcb.__Continue__ = __Continue__
fcb.__Break__ = __Break__


<suite> is compiled using following code transformations:
  value expr   ==> return expr # needs new keyword!, produce value

  return expr  ==> raise __Return__,expr # i.e. non-local return

  yield : not supported!!! (simple generators and first-class blocks do not 
mix)

maybe:
  break        ==> raise __Break__ # i.e. non-local break
  continue     ==> raise __Continue__ # i.e. non-local continue

- * -

'do' statement:

[x... ?=] do expr: [(args)]: # ?= stands for all possible assignment forms
   <suite>

equivalent to:

on _anonym[(args)]:
   <suite>
try:
   [x... ?=] expr(_anonym)
except __Return__,_ret: # if meaningful; _ret should be user-invisible
   return _ret.args[0]
except __Continue__: # if meaningful
   continue
except __Break: # if meaningful
   break

Example:

def list10(pfx):
  do repeat(10): (i):
    print pfx,i

<===>

def list10(pfx):
   class __Break__(Exception?): pass
   class __Return__(Exception?): pass
   class __Continue__(Exception?): pass
   BLOCK _anonym(i):
    print pfx,i
   _anonym.__Break__ = __Break__
   _anonym.__Continue__ = __Continue__
   _anonym.__Return__ = __Return__
   try:
     repeat(10)(_anonym)
   except __Return__,_ret:
     return _ret.args[0]

Some global built-in __Return__,etc. could do, but using locally defined 
ones, let people call _anonym inside a 'do' inside expr resulted callable 
getting the "expected" behavior.

Notice: a user accessible 'on' construct is not necessary for 'do' but see 
next.

- * -

Further:

~First-class explicit blocks are to complex user-defined statements what 
methods are to classes~

'do**' statement:

[x... ?=] do** expr: [(args)]:
   <suite>

semantics:

build dict _suite_dict out of <suite> (same as 'class' statement):

try:
   [x... ?=] expr(**_suite_dict)
except __Return__,_ret: # if meaningful, _ret should be user-invisible
   return _ret.args[0]
except __Continue__: # if meaningful
   continue
except __Break: # if meaningful
   break

expr resulted callable should use _suite_dict only in a read-only way (let 
the door open to some optimizations?)

examples:

do** tryfin: # contrived
   on try_:
     <suite>
   on finally_:
     <suite>


class C(object):
   v = do** property: # with suitable property def
     def get...: ...
     def set...: ...

Yes, do** is kind of an awful keyword.

- * -

Needed keywords: one for each of 'do','do**','on','value'

- * -

Possible further extensions, tentative syntax:

inside do** <suite>s allow for assigment/defs statements of the form:
   def [expr](...): ... # no here [] mean really '['']' not optional
   on [expr]...
   [expr] ?= ... # assignment forms

which would have more-or-less semantics:

   [expr] ?= ... <===> locals()[expr] ?= ...

although a special bytecode would be probably used. And then expr result 
would have to be called as in

expr(_suite_dict)

because non-string keywords are not supported and not simply ignored [at 
least now].

then:

do** except: # contrived
   on try_:
     ...
   on [ExcClass1]:
     ...
   on [(ExcClass2,ExcClass3)] (e):
     ...

If exec would work properly with subclasses of dict [that's not the case 
now] do** expr could have a __make_ns__ attribute so that a specialized 
kind of dict could be used (multi-key or remembering the order by which 
items were set, etc.)

_exv = expr
if hasattr(_exv,'__make_ns__'):
   _ns = _exv.__make_ns__()
else:
   _ns = {}
exec <suite-code> in _ns
try:
   _exv(_ns)
   ...

That's all.



From customercare@ebates.com  Sat Jun  7 17:13:38 2003
From: customercare@ebates.com (EBATES - Customer Care)
Date: Sat, 07 Jun 2003 09:13:38  -0700
Subject: [Python-Dev] Re: Re: Your application [#1607045]
Message-ID: <eGain@16565Sat07Jun200309.13.38>

Dear Valued Customer, 

Thank you for contacting Customer Care at Ebates. We have received your request and a Customer Care Associate will respond to you soon.  Currently, our office is open Monday through Friday.  We appreciate your patronage and look forward to assisting you.

Sincerely,

Customer Care
Ebates


----- <python-dev python.org> Wrote -----
Please see the attached file.
===========================================================================
WARNING: This e-mail has been altered by MIMEDefang.  Following this
paragraph are indications of the actual changes made.  For more
information about your site's MIMEDefang policy, contact
Administrator <defang-admin@ebates.com>.  For more information about MIMEDefang, see:

            http://www.roaringpenguin.com/mimedefang/enduser.php3

An attachment named "approved.pif was removed from this document as it
constituted a security hazard.  If you require this document, please contact
the sender and arrange an alternate means of receiving it.






From martin@v.loewis.de  Sat Jun  7 18:50:43 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 07 Jun 2003 19:50:43 +0200
Subject: [Python-Dev] The Python interpreter is not fully thread-safe.
Message-ID: <m34r31hj4c.fsf@mira.informatik.hu-berlin.de>

I'd like to replace the first sentence of 8.1 in the API reference
with

"The Python interpreter does not support \emph{free} threading."

Any library that *is* "fully thread-safe" establishes certain
conventions that users have to follow to achieve thread-safety. The
same is true for Python: if the conventions (which are elaborated in
section 8.1) are followed, Python is also fully thread-safe. It's just
that it does not support what is commonly called "free threading".

Any objections?

Regards,
Martin



From niemeyer@conectiva.com  Sat Jun  7 18:57:37 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Sat, 7 Jun 2003 14:57:37 -0300
Subject: [Python-Dev] urllib2 proxy support broken?
Message-ID: <20030607175737.GA2242@ibook>

> > I've just tried to use the proxy support in urllib2, and was surprised
> > by the fact that it seems to be broken, at least in 2.2 and 2.3. Can
> > somebody please confirm that it's really broken, so that I can prepare
> > a patch?
> 
> Ok.. I have prepared a simple fix for this, and sent it to SF patch
> #742823. This fix should be backwards compatible, and at the same time
> allows any kind of further customization of pre-defined and user-defined
> classes.

FWIW, I've applied the patch. Any tests with existing applications
will be welcome.

-- 
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]


From aahz@pythoncraft.com  Sat Jun  7 20:17:14 2003
From: aahz@pythoncraft.com (Aahz)
Date: Sat, 7 Jun 2003 15:17:14 -0400
Subject: [Python-Dev] The Python interpreter is not fully thread-safe.
In-Reply-To: <m34r31hj4c.fsf@mira.informatik.hu-berlin.de>
References: <m34r31hj4c.fsf@mira.informatik.hu-berlin.de>
Message-ID: <20030607191714.GA29227@panix.com>

On Sat, Jun 07, 2003, Martin v. L=F6wis wrote:
>
> I'd like to replace the first sentence of 8.1 in the API reference
> with
>=20
> "The Python interpreter does not support \emph{free} threading."

+1
--=20
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.=
com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From fdrake@acm.org  Sat Jun  7 21:17:51 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sat, 7 Jun 2003 16:17:51 -0400
Subject: [Python-Dev] The Python interpreter is not fully thread-safe.
In-Reply-To: <m34r31hj4c.fsf@mira.informatik.hu-berlin.de>
References: <m34r31hj4c.fsf@mira.informatik.hu-berlin.de>
Message-ID: <16098.18544.576.875922@grendel.zope.com>

Martin v. L=F6wis writes:
 > I'd like to replace the first sentence of 8.1 in the API reference
 > with
 >=20
 > "The Python interpreter does not support \emph{free} threading."

+1


  -Fred

--=20
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation


From fdrake@acm.org  Sat Jun  7 21:27:27 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sat, 7 Jun 2003 16:27:27 -0400
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib pprint.py,1.24,1.25
In-Reply-To: <E19Ok7l-0002iC-00@sc8-pr-cvs1.sourceforge.net>
References: <E19Ok7l-0002iC-00@sc8-pr-cvs1.sourceforge.net>
Message-ID: <16098.19119.108016.744300@grendel.zope.com>

loewis@users.sourceforge.net writes:
 > Modified Files:
 > 	pprint.py 
 > Log Message:
 > Patch #750542: Use issubclass instead of type identity.

Hmm; this patch was never assigned to me, so I was unaware that anyone
thought there was a problem with this.

I specifically considered making changes like these when subclassing
built-in types became possible, but decided against it since it didn't
appear reasonable to assume that __repr__() hadn't been redefined.
I'm sure it's possible to check, but to do so cleanly and efficiently
seems like a huge change to the module for little value.

I think the patch, as it stands, should be reverted.  If another patch
appears that addresses the issue of overridden __repr__() methods, it
should be considered again.

-1 for the patch as applied.


  -Fred

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


From martin@v.loewis.de  Sat Jun  7 21:49:39 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 07 Jun 2003 22:49:39 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib pprint.py,1.24,1.25
In-Reply-To: <16098.19119.108016.744300@grendel.zope.com>
References: <E19Ok7l-0002iC-00@sc8-pr-cvs1.sourceforge.net>
 <16098.19119.108016.744300@grendel.zope.com>
Message-ID: <m3znktfw9o.fsf@mira.informatik.hu-berlin.de>

"Fred L. Drake, Jr." <fdrake@acm.org> writes:

> I think the patch, as it stands, should be reverted. 

Done!

Martin


From python@rcn.com  Sat Jun  7 21:51:58 2003
From: python@rcn.com (Raymond Hettinger)
Date: Sat, 7 Jun 2003 16:51:58 -0400
Subject: [Python-Dev] The Python interpreter is not fully thread-safe.
References: <m34r31hj4c.fsf@mira.informatik.hu-berlin.de>
Message-ID: <003c01c32d36$a3745560$e315c797@oemcomputer>

From: "Martin v. Löwis"
> I'd like to replace the first sentence of 8.1 in the API reference
> with
>
> "The Python interpreter does not support \emph{free} threading."

Perhaps add an elaboration for those who do not fully grok
the significance of "free threading".  This block of text would
meet the need nicely:

   > Any library that *is* "fully thread-safe" establishes certain
   > conventions that users have to follow to achieve thread-safety. The
   > same is true for Python: if the conventions (which are elaborated in
   > section 8.1) are followed, Python is also fully thread-safe. It's just
   > that it does not support what is commonly called "free threading".



Raymond Hettinger



From tim.one@comcast.net  Sat Jun  7 22:54:51 2003
From: tim.one@comcast.net (Tim Peters)
Date: Sat, 07 Jun 2003 17:54:51 -0400
Subject: [Python-Dev] The Python interpreter is not fully thread-safe.
In-Reply-To: <m34r31hj4c.fsf@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEEDEJAB.tim.one@comcast.net>

[Martin v. L=F6wis]
> I'd like to replace the first sentence of 8.1 in the API reference
> with
>
> "The Python interpreter does not support \emph{free} threading."

I agree it should change, but doubt this rephrasing would help much. =
 Do a
Google search on "free threading", and you'll find that all the top h=
its are
about Microsoft, or about Python (thanks to GregS and MarkH importing=
 this
MS terminology into PythonLand).  People on other OSes aren't likely =
to have
a clue what it means.  I can predict that with confidence because I h=
ad no
idea what they were talking about when I first heard the term in Pyth=
onLand,
and despite working in the parallel processing biz at the time <wink>=
.

For most people, I believe "thread safe" means that a collection of A=
PI
calls is safe to make without any special dances.  For example, under=
 some
Unix flavors, routines whose names end with _r are the "thread safe"
versions of routines without the trailing _r.

Under that meaning (which I believe Guido also had in mind when he wr=
ote
this section), Python's C API is indeed not thread-safe.  We don't ha=
ve to
apologize for that, though, we just have to spell out what's needed i=
n the
presence of threads.  Since people are apt to misunderstand the inten=
ded
meanings of both "thread safe" and "free threading", better to just e=
xplain
what's needed than to shoot for buzzword compliance.




From fdrake@acm.org  Sat Jun  7 22:57:06 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sat, 7 Jun 2003 17:57:06 -0400
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib pprint.py,1.24,1.25
In-Reply-To: <m3znktfw9o.fsf@mira.informatik.hu-berlin.de>
References: <E19Ok7l-0002iC-00@sc8-pr-cvs1.sourceforge.net>
 <16098.19119.108016.744300@grendel.zope.com>
 <m3znktfw9o.fsf@mira.informatik.hu-berlin.de>
Message-ID: <16098.24498.247947.882455@grendel.zope.com>

Martin v. L=F6wis writes:
 > Done!

Thanks.

I'll note that I'm not against the idea, but getting the semantics
just right won't be nearly so easy.  If someone does the work to
figure it out and produces a working patch, I'll be more than happy to
take a look at it.

I'd also be interested in proposals for a parallel to __repr__() that
the pprint module could use; perhaps a __pformat__() method?  Hmm.


  -Fred

--=20
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation


From fdrake@acm.org  Sat Jun  7 22:59:04 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sat, 7 Jun 2003 17:59:04 -0400
Subject: [Python-Dev] The Python interpreter is not fully thread-safe.
In-Reply-To: <003c01c32d36$a3745560$e315c797@oemcomputer>
References: <m34r31hj4c.fsf@mira.informatik.hu-berlin.de>
 <003c01c32d36$a3745560$e315c797@oemcomputer>
Message-ID: <16098.24616.142003.807116@grendel.zope.com>

Raymond Hettinger writes:
 > Perhaps add an elaboration for those who do not fully grok
 > the significance of "free threading".  This block of text would
 > meet the need nicely:

What's already there is reasonable, but this would make a nice
addition.  Feel free to check it in if Martin's says it's ok to use
his words (or he can check them in).


  -Fred

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


From drifty@alum.berkeley.edu  Sun Jun  8 00:26:20 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Sat, 07 Jun 2003 16:26:20 -0700
Subject: [Python-Dev] python-dev Summary for 2003-05-16 through 2003-05-31
Message-ID: <3EE2749C.4050205@ocf.berkeley.edu>

Here is the rough of the summary, as usual.  I will not send it out any 
earlier than Tuesday.

-------------------------


python-dev Summary for 2003-05-16 through 2003-05-31
++++++++++++++++++++++++++++++++++++++++++++++++++++
This is a summary of traffic on the `python-dev mailing list`_ from May 
16, 2003 through May 31, 2003.  It is intended to inform the wider 
Python community of on-going developments on the list and to have an 
archived summary of each thread started on the list.  To comment on 
anything mentioned here, just post to python-list@python.org or 
`comp.lang.python`_ with a subject line mentioning what you are 
discussing. All python-dev members are interested in seeing ideas 
discussed by the community, so don't hesitate to take a stance on 
something.  And if all of this really interests you then get involved 
and join `python-dev`_!

This is the eighteenth summary written by Brett Cannon (has his own room 
with a door for the first time in over 22 years).

All summaries are archived at http://www.python.org/dev/summary/ .

Please note that this summary is written using reStructuredText_ which 
can be found at http://docutils.sf.net/rst.html .  Any unfamiliar 
punctuation is probably markup for reST_ (otherwise it is probably 
regular expression syntax or a typo =); you can safely ignore it, 
although I suggest learning reST; its simple and is accepted for `PEP 
markup`__.  Also, because of the wonders of programs that like to 
reformat text, I cannot guarantee you will be able to run the text 
version of this summary through Docutils_ as-is unless it is from the 
original text file.

__ http://www.python.org/peps/pep-0012.html

The in-development version of the documentation for Python can be found 
at http://www.python.org/dev/doc/devel/ and should be used when wanting 
to look up any documentation on something mentioned here.  To view files 
in the Python CVS online, go to 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .

.. _python-dev: http://www.python.org/dev/
.. _python-dev mailing list: 
http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html

.. contents::


.. _last summary: 
http://www.python.org/dev/summary/2003-05-01_2003-05-15.html




======================
Summary Announcements
======================
Sorry about the delay for this summary.  I was visiting my mother and 
that puts me out of my hacking groove.  I also had a roommate move out 
which means I got to move into his room.  And on top of all of that I am 
having to decide which school to attend to get my CS masters.  Life just 
likes to dump everything on you at once, huh?


====================================
`Vacation; Python 2.2.3 release.`__
====================================
__ http://mail.python.org/pipermail/python-dev/2003-May/035642.html

Related threads:
     - `Preparing docs for Python 2.2.3`__
     - `Python 2.2.3`__
     - `One other 2.2.3 failure`__
     - `RELEASED Python 2.2.3c1`__
     - `_sre changes`__
     - `Python bug 544473 - bugfix candidate - was it applied?`__
     - `Plans for Python 2.2.3 final`__
     - Python 2.2.3 docs freeze`__
     - RELEASED Python 2.2.3 (final)`__

__ http://mail.python.org/pipermail/python-dev/2003-May/035796.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035797.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035801.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035807.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035835.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035851.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035856.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035872.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035905.html

`Python 2.2.3`_ has gone out the door!

.. _Python 2.2.3: http://www.python.org./2.2.3/


===============================
`C new-style classes and GC`__
===============================
__ http://mail.python.org/pipermail/python-dev/2003-May/035661.html

Jim Fulton updated the tutorial for creating new C types to use 
new-style classes.  This led to the question of what the right way was 
for dealing with garbage collection.  In terms of the tp_dealloc slot, 
having it call obj->ob_type->tp_free is best since that works the best 
when the type is subclassed.

This also led to a discussion about the magic of PyType_Ready and 
whether it should do more.  This wonderful function fills in tp_alloc 
and tp_free if tp_base and tp_bases are empty (they are set 
appropriately for PyBaseObject which is the C version of object).  What 
was changed was that now the function does the right thing if the object 
should be checked for cycles based on settings in tp_flags.

Paul Moore was worried about the loss of the tutorial for classic types. 
  The response was that as long as they don't mess with there code it 
will continue to work, but if they decide to change something they 
should probably update.  Michael Hudson's Misc/pymemcompat.h file is 
also helpful since it allows you to use 2.3's memory API but 
macro-replaces the call with the proper code all the way back to 1.5.2 . 
  It was suggested adding a Misc/pyapipcompat.h for PyAPI_FUNC, 
PyAPI_DATA, and PyMODINIT_FUNC.


=====================
`Attribute lookup`__
=====================
__ http://mail.python.org/pipermail/python-dev/2003-May/035730.html

For the last summary I asked for the help of python-dev to find out the 
exact algorithm used to do attribute lookup for new-style classes (I 
don't care about classic classes since they are sooo 2.1  =).  A bunch 
of people jumped in and made suggestions, but I am going to steal the 
explanation from Raymond Hettinger's explanation of descriptors which he 
is working on since I am reading it as I write this.  =)

The attribute lookup order gives "data descriptors priority over 
instance variables, instance variables priority over non-data 
descriptors, and assigns lowest priority to __getattr__ if provided." 
This is all is done by object.__getattribute__ .  If you define your own 
__getattribute__ none of this is done unless you  explicitly call 
object's implementation.  You have to worry about calling a descriptor's 
__get__ method yourself if you decide not to call object.__getattribute__ .

Raymond's descriptor essay/explanation/(group of words put together in 
attempt to make a coherent idea which he does) explains the difference 
between a data descriptor and non-data descriptor, but instead of make 
you wait I will just tell you.  A data descriptor defines both a __get__ 
and __set__ method while a non-data descriptor defines only __get__. 
This makes sense when you think about non-data-descriptors such as 
functions.  You have no need to assign to a function so not having a 
__set__ in no way harms the usage of a function plus it negates the need 
for any special flag or anything to define the difference between data 
and non-data descriptors.


=================
`Introduction`__
=================
__ http://mail.python.org/pipermail/python-dev/2003-May/035792.html

Splinter threads:
     - `Contracts PEP`__

__ http://mail.python.org/pipermail/python-dev/2003-May/035864.html

What started off as Jeffrey Robert's introducing himself ended up 
becoming a short howto on how to get involved on python-dev.  It was 
suggested to work on pyPy_ (although that is not exactly python-dev but 
is still cool and you could learn a lot about Python on a more abstract 
level =).  Multiple people suggested working on bugs and patches.  I 
specifically suggested looking at patches in development to learn what 
they were doing to the code's semantics.  Mention of the AST branch and 
working on that was also brought up.

Terrence Way then introduced himself and mentioned he had written a PEP 
about programming with contracts.  It led to, in the end, Guido saying 
that he wanted to wait and let more implementations get out there and be 
weeded out before he started pronouncing on PEPs on the subject.

.. _pyPy: http://codespeak.net/pypy/index.cgi?home


=========
Quickies
=========
`test_urllibnet failing on Windows`__
     os.fdopen does not work with sockets under Windows when fetching 
its argument from fileno .

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035655.html

`[development doc updates]`__
     Here is a simple intelligence test: what do you think this email 
was about based on its subject?  Get it right and you earned yourself a 
lollipop (on your own dime).

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035660.html

`test_time fails with current CVS`__
     No follow-up to this email so I don't know if MA Lemburg's issue 
with time.tzset was solved.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035669.html

`a strange case`__
     Splinter threads:
         `Unifying modules and classes?`__

     Apparently the 2.2.x branch allows you to subclass a module.  This 
has been fixed in 2.3 .  And once again Guido stated that erasing the 
line separating classes and modules is not going to happen while his 
benevolently dictating body still has air in it (okay, he didn't say it 
that way, but I am sure he wouldn't object to a little artistic license 
to get his point across =).  But if you really feel the need to have a 
module be a class just stick an instance in sys.modules; just don't 
expect everything to play well with it, though.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035676.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035731.html

`test_bsddb185 failing under OS X`__
     Tests were failing for me under OS X.  After Skip Montanaro and I 
independently came up with a better way for the test to clean up after 
itself the tests passed from some odd reason.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035699.html

`Need advice, maybe support`__
     Christian Tismer was given two bits in tp_flags for Stackless_.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035701.html
.. _Stackless: http://www.stackless.com./

`[Python-Dev] SF oddity`__
     Remember folks, look out for horizontal scroll bars along with 
vertical ones.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035713.html

Weekly Python Bug/Patch Summary
     * Ending on `2003-05-18`__
     * Ending on `2003-05-25`__

__ http://mail.python.org/pipermail/python-dev/2003-May/035716.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035834.html

`doctest extensions`__
     Jim Fulton came up with some possible additions for doctest.  You 
can see them at 
http://cvs.zope.org/Zope3/src/zope/testing/doctestunit.py?rev=HEAD&content-type=text/vnd.viewcvs-markup 
.  If you would like to see them added then speak up.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035718.html

`+= on return of function call result`__
     This is a continuation from `last summary`_.
     Samuele Pedroni wrote a simple function that simulates what was 
originally desired.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035500.html

`Using emacs' unexec to speed Python startup`__
     Splinter threads:
         - `portable undumper in xemacs`__

     Some people tried  to speed up loading Python for `some editor`__ 
when what they should have been doing is learning how to use a `better 
editor`__.  =)

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035727.html
__ http://mail.python.org/pipermail/python-dev/2003-May/035769.html

.. _some editor: http://www.gnu.org/software/emacs/emacs.html
.. _better editor: http://www.vim.org/

`[debian build error]`__
     Some issue with using Debian packages and Python 2.2 with gcc 3.3 
and libstdc++5.  A Debian bug report has been filed.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035747.html

`urllib2 proxy support broken?`__
     Yes, but Gustavo Niemeyer would found the bug also came up with a 
patch.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035764.html

`Python Run-Time System and Extensions`__
     Daniel Silva is writing a compiler for Python to `PLT Scheme`_ 
code.  He asked for suggestions on which of two ways to go for being 
able to run C extension code.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035773.html
.. _PLT Scheme: http://www.plt-scheme.org/

`Descriptor API`__
     We all learned what the difference is between a data and non_data 
descriptor (which you can know too by reading the summary for `Attribute 
lookup`_ ).

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035788.html

`Of what use is commands.getstatus()`__
     Guido ended up saying the commmands module should be redesigned, 
probably put into shutil, and then have the old version deprecated.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035799.html

`Change to ossaudiodev setparameters() method`__
     Some day Greg Ward will get his ossaudiodev module to work on both 
Guido's home machine and work machine.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035840.html

`RE: Decimal class`__
     A Decimal class is currently being worked on in the CVS sandbox. 
The question as to whether the values should be immutable was raised. 
Everyone agreed the change should happen.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035844.html

`install debian package`__
     python-dev is not the right place to bring up issues with Debian 
packages.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035849.html

`Release question`__
     Branches in CVS for Python are pretty much only used for minor 
versions (the "3" in "2.3.x").  Since 2.3 is in beta that means no 
semantic changes to the code.  Any new features must wait for 2.4 
development to start which occurs when 2.3 is out the door.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035873.html

`Algoritmic Complexity Attack on Python`__
     Someone tried to point out that Python was vulnerable to an attack 
if you naively took in certain things as keys to a dictionary.  The big 
lesson is that Python's hash function can changes between releases and 
that it will always be as fast as possible.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035874.html

`KeyboardInterrupt on Windows`__
     An optimization on looping and using the JUMP_ABSOLUTE opcode was 
not catching exceptions since it was skipping that check in the 
interpreter loop.  It has been fixed.

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035890.html

`more-precise instructions for "Python.h first"?`__
     David Abrahams didn't like the restriction of having to put 
Python.h before all other headers in C/C++ code.  It is still being 
considered to make it so it is Python.h or pyconfig.h .

.. __: http://mail.python.org/pipermail/python-dev/2003-May/035908.html



From Jack.Jansen@cwi.nl  Sun Jun  8 00:55:30 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Sun, 8 Jun 2003 01:55:30 +0200
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: <m3adcvgonx.fsf@mira.informatik.hu-berlin.de>
Message-ID: <84FD9D85-9943-11D7-BD99-000A27B19B96@cwi.nl>

On vrijdag, jun 6, 2003, at 18:24 Europe/Amsterdam, Martin v. L=F6wis=20
wrote:

> Jack Jansen <Jack.Jansen@cwi.nl> writes:
>
>> Shouldn't it be in lib-tk/idlelib? Or has idle been factored so that
>> it is potentially useable with another GUI package?
>
> No, but... What advantage would be gained by a deeper nesting?

Uhm... Nothing really:-) except that everything that depends on Tkinter=20=

is in there, I thought this was by design (so you can remove it if you=20=

aren't interested in Tkinter).
--
- Jack Jansen        <Jack.Jansen@oratrix.com>       =20
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma=20
Goldman -



From martin@v.loewis.de  Sun Jun  8 07:51:35 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 08 Jun 2003 08:51:35 +0200
Subject: [Python-Dev] The Python interpreter is not fully thread-safe.
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEEDEJAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCCEEDEJAB.tim.one@comcast.net>
Message-ID: <m3u1b1vz7s.fsf@mira.informatik.hu-berlin.de>

Tim Peters <tim.one@comcast.net> writes:

> I agree it should change, but doubt this rephrasing would help much.  Do a
> Google search on "free threading", and you'll find that all the top hits are
> about Microsoft, or about Python (thanks to GregS and MarkH importing this
> MS terminology into PythonLand).  People on other OSes aren't likely to have
> a clue what it means.  

True. I think I'll add a footnote as well.

> For most people, I believe "thread safe" means that a collection of API
> calls is safe to make without any special dances.  For example, under some
> Unix flavors, routines whose names end with _r are the "thread safe"
> versions of routines without the trailing _r.

Actually, Unix people tend to call those "re-entrant"; this is what
the _r suffix suggests, anyway. It is almost correct to say that the
Python API is not re-entrant. 

However, traditionally, this term was defined as "re-enter the
function while it is being running". In this definition, the Python
API *does* support certain kinds of reentrancy, namely those where the
API is re-entered from the same thread.

> Under that meaning (which I believe Guido also had in mind when he wrote
> this section), Python's C API is indeed not thread-safe.  We don't have to
> apologize for that, though, we just have to spell out what's needed in the
> presence of threads.

This request was triggered by a question from c.l.p: "When will Python
be thread-safe". It was not obvious that the poster was referring to
the API docs, so the initial responses all were "Python *is* thread-safe".

Regards,
Martin



From martin@v.loewis.de  Sun Jun  8 07:55:16 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 08 Jun 2003 08:55:16 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib pprint.py,1.24,1.25
In-Reply-To: <16098.24498.247947.882455@grendel.zope.com>
References: <E19Ok7l-0002iC-00@sc8-pr-cvs1.sourceforge.net>
 <16098.19119.108016.744300@grendel.zope.com>
 <m3znktfw9o.fsf@mira.informatik.hu-berlin.de>
 <16098.24498.247947.882455@grendel.zope.com>
Message-ID: <m3ptlpvz1n.fsf@mira.informatik.hu-berlin.de>

"Fred L. Drake, Jr." <fdrake@acm.org> writes:

> I'll note that I'm not against the idea, but getting the semantics
> just right won't be nearly so easy.  If someone does the work to
> figure it out and produces a working patch, I'll be more than happy to
> take a look at it.

I felt that the semantics of pprint are sufficiently vague so that
trading one instance of "correct" vs. another is acceptable. pprint
should be used for debugging output only, where the specifics of the
output are not that relevant, as long as it looks "pretty".

In any case, I have told Gerrit your ruling; we'll see whether he
comes back with a new patch.

Regards,
Martin


From martin@v.loewis.de  Sun Jun  8 08:01:40 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 08 Jun 2003 09:01:40 +0200
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: <84FD9D85-9943-11D7-BD99-000A27B19B96@cwi.nl>
References: <84FD9D85-9943-11D7-BD99-000A27B19B96@cwi.nl>
Message-ID: <m3llwdvyqz.fsf@mira.informatik.hu-berlin.de>

Jack Jansen <Jack.Jansen@cwi.nl> writes:

> Uhm... Nothing really:-) except that everything that depends on
> Tkinter is in there, I thought this was by design (so you can remove
> it if you aren't interested in Tkinter).

I think the original motivation for the lib-tk subdirectory was the
ability to add or remove it from sys.path, through
Modules/Setup. These days, nobody edits Modules/Setup anymore, so I'd
question its usefulness (it should be preserved for compatibility, of
course).

OTOH, I don't feel strongly about this, and would trust the decision
in Kurt's hands.

Regards,
Martin



From just@letterror.com  Sun Jun  8 09:47:13 2003
From: just@letterror.com (Just van Rossum)
Date: Sun,  8 Jun 2003 10:47:13 +0200
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: <84FD9D85-9943-11D7-BD99-000A27B19B96@cwi.nl>
Message-ID: <r01050400-1026-D7C57F43998D11D7ABF2003065D5E7E4@[10.0.0.23]>

Jack Jansen wrote:

> > No, but... What advantage would be gained by a deeper nesting?
> 
> Uhm... Nothing really:-) except that everything that depends on
> Tkinter is in there, I thought this was by design (so you can remove
> it if you aren't interested in Tkinter).

Well, _much_ of Idle depends in Tk, but not everything. There is quite
some good stuff in there that is either directly useful for other IDE
writers, or at least have the potential to be refactored to that effect. 

(That said, if Idle ends up in Lib/, it should really be a package since
it contains quite a few modules with rather generic names; but I assume
that's indeed the plan, given the comment in IdleFork's __init__.py
file.)

Just


From gerrit@nl.linux.org  Sun Jun  8 10:37:11 2003
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Sun, 8 Jun 2003 11:37:11 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib pprint.py, 1.24, 1.25
In-Reply-To: <m3ptlpvz1n.fsf@mira.informatik.hu-berlin.de>
References: <E19Ok7l-0002iC-00@sc8-pr-cvs1.sourceforge.net> <16098.19119.108016.744300@grendel.zope.com> <m3znktfw9o.fsf@mira.informatik.hu-berlin.de> <16098.24498.247947.882455@grendel.zope.com> <m3ptlpvz1n.fsf@mira.informatik.hu-berlin.de>
Message-ID: <20030608093711.GA2393@nl.linux.org>

Hello,

Since my last post here is >3 years old, I'll introduce myself: I am
Gerrit Holl (17) from Diemen (Amsterdam), I'm between school and
university (Physics), I learned programming using Python 4 1/2 years
ago and it's still the only real language I know, so I'm far from an
expert in computer science. I have been lurking this mailinglist for
approximately half a year now.

Martin v. Löwis wrote:
> "Fred L. Drake, Jr." <fdrake@acm.org> writes:
> 
> > I'll note that I'm not against the idea, but getting the semantics
> > just right won't be nearly so easy.  If someone does the work to
> > figure it out and produces a working patch, I'll be more than happy to
> > take a look at it.
> 
> I felt that the semantics of pprint are sufficiently vague so that
> trading one instance of "correct" vs. another is acceptable. pprint
> should be used for debugging output only, where the specifics of the
> output are not that relevant, as long as it looks "pretty".
> 
> In any case, I have told Gerrit your ruling; we'll see whether he
> comes back with a new patch.

Would it be an acceptable solution to check whether __repr__ has changed?

Something like:

    if issubclass(typ, dict) and type(typ.__repr__) is type(dict.__repr__):
        # do stuff

Objects that don't change __repr__ can "safely" be pprinted, objects that
do but still want to pprint their data can subclass PrettyPrinter.

If this is considered a correct change, I will attach a new patch to SF#750542.

yours,
Gerrit.

-- 
114. If a man have no claim on another for corn and money, and try to
demand it by force, he shall pay one-third of a mina of silver in every
case.
        -- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
	http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
	http://www.sp.nl/


From skip@mojam.com  Sun Jun  8 13:00:26 2003
From: skip@mojam.com (Skip Montanaro)
Date: Sun, 8 Jun 2003 07:00:26 -0500
Subject: [Python-Dev] Weekly Python Bug/Patch Summary
Message-ID: <200306081200.h58C0QU23102@manatee.mojam.com>

Bug/Patch Summary
-----------------

381 open / 3691 total bugs (+11)
151 open / 2195 total patches (+4)

New Bugs
--------

rfc2822 formatdate functionality duplication (2003-06-01)
	http://python.org/sf/747320
make test errors Tru64 UNIX V5.1A (2003-06-02)
	http://python.org/sf/747460
broken ncurses support in current cvs a last distribution (2003-06-04)
	http://python.org/sf/748926
last threads fixes broke linker (2003-06-04)
	http://python.org/sf/748928
bdist --formats=zip,wininst and bdist --formats=wininst,zip (2003-06-04)
	http://python.org/sf/749210
os.path.split does not handle . & .. properly (2003-06-04)
	http://python.org/sf/749261
strange  __subclasses__ behaviour (2003-06-05)
	http://python.org/sf/749480
copy raises SystemError when getstate raises exception (2003-06-05)
	http://python.org/sf/749831
--enable-shared fails on Solaris 9 with gcc-3.2.3 (2003-06-05)
	http://python.org/sf/749911
exec documentation not updated (2003-06-06)
	http://python.org/sf/750092
Pickle fails to restore new-style class instance in a cycle (2003-06-06)
	http://python.org/sf/750328
event handling support (2003-06-06)
	http://python.org/sf/750423

New Patches
-----------

BaseHTTPServer doesn't need StringIO intermediary (2003-06-02)
	http://python.org/sf/747364
Nails down the semantics of dict setitem (2003-06-03)
	http://python.org/sf/748126
Let Email.Utils.parsedate use last 3 timetuple items (2003-06-04)
	http://python.org/sf/748843
Describe formation of method objects more accurately (2003-06-04)
	http://python.org/sf/749012
allow UNIX mmap size to default to current file size (2003-06-05)
	http://python.org/sf/749830
'compiler' module bug with 'import foo.bar as baz' (2003-06-06)
	http://python.org/sf/750008

Closed Bugs
-----------

Can't compile when using alt. thread lib when pthread avail. (2002-04-11)
	http://python.org/sf/542482
Configure does NOT set properly *FLAGS for thread support (2003-05-21)
	http://python.org/sf/741307
indentation error in unixcompiler.py (2003-06-01)
	http://python.org/sf/746953

Closed Patches
--------------

Compiler warning on Solaris 8 (2003-04-28)
	http://python.org/sf/729305
SpawnedGenerator class for threading module (2003-05-02)
	http://python.org/sf/731701
Ordering of handlers in urllib2 (2003-05-24)
	http://python.org/sf/742823
FreeBSD 4 port of python-2.2.3... (2003-05-31)
	http://python.org/sf/746801


From aleaxit@yahoo.com  Sun Jun  8 16:40:53 2003
From: aleaxit@yahoo.com (Alex Martelli)
Date: Sun, 8 Jun 2003 17:40:53 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib pprint.py, 1.24, 1.25
In-Reply-To: <20030608093711.GA2393@nl.linux.org>
References: <E19Ok7l-0002iC-00@sc8-pr-cvs1.sourceforge.net> <m3ptlpvz1n.fsf@mira.informatik.hu-berlin.de> <20030608093711.GA2393@nl.linux.org>
Message-ID: <200306081740.53580.aleaxit@yahoo.com>

On Sunday 08 June 2003 11:37 am, Gerrit Holl wrote:
   ...
>     if issubclass(typ, dict) and type(typ.__repr__) is type(dict.__repr__):
>         # do stuff

Aren't the calls to type() here wrong?  It seems to me that what you want
to check is just whether typ.__repr__ is dict.__repr__, not if the types of 
the two bound methods are the same.


Alex



From gerrit@nl.linux.org  Sun Jun  8 17:09:08 2003
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Sun, 8 Jun 2003 18:09:08 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib pprint.py, 1.24, 1.25
In-Reply-To: <200306081740.53580.aleaxit@yahoo.com>
References: <E19Ok7l-0002iC-00@sc8-pr-cvs1.sourceforge.net> <m3ptlpvz1n.fsf@mira.informatik.hu-berlin.de> <20030608093711.GA2393@nl.linux.org> <200306081740.53580.aleaxit@yahoo.com>
Message-ID: <20030608160908.GA21514@nl.linux.org>

Hi,

Alex Martelli wrote:
> >     if issubclass(typ, dict) and type(typ.__repr__) is type(dict.__repr__):
> >         # do stuff
> 
> Aren't the calls to type() here wrong?  It seems to me that what you want
> to check is just whether typ.__repr__ is dict.__repr__, not if the types of 
> the two bound methods are the same.

I was confused: I thought methods were dynamically created, but that is
only true for bound methods, not for unbound methods. typ.__repr__ is
dict.__repr__ is correct indeed.

yours,
Gerrit.

-- 
252. If he kill a man's slave, he shall pay one-third of a mina.
        -- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
	http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
	http://www.sp.nl/


From Jack.Jansen@cwi.nl  Sun Jun  8 17:32:25 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Sun, 8 Jun 2003 18:32:25 +0200
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: <r01050400-1026-D7C57F43998D11D7ABF2003065D5E7E4@[10.0.0.23]>
Message-ID: <C9CD6A6E-99CE-11D7-8A53-000A27B19B96@cwi.nl>

On zondag, jun 8, 2003, at 10:47 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>>> No, but... What advantage would be gained by a deeper nesting?
>>
>> Uhm... Nothing really:-) except that everything that depends on
>> Tkinter is in there, I thought this was by design (so you can remove
>> it if you aren't interested in Tkinter).
>
> Well, _much_ of Idle depends in Tk, but not everything. There is quite
> some good stuff in there that is either directly useful for other IDE
> writers, or at least have the potential to be refactored to that 
> effect.

Ok, that answers the original question I was asking. Then it indeed 
belongs straight under Lib.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From pedronis@bluewin.ch  Sun Jun  8 17:57:01 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Sun, 08 Jun 2003 18:57:01 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib
 pprint.py, 1.24, 1.25
In-Reply-To: <20030608160908.GA21514@nl.linux.org>
References: <200306081740.53580.aleaxit@yahoo.com>
 <E19Ok7l-0002iC-00@sc8-pr-cvs1.sourceforge.net>
 <m3ptlpvz1n.fsf@mira.informatik.hu-berlin.de>
 <20030608093711.GA2393@nl.linux.org>
 <200306081740.53580.aleaxit@yahoo.com>
Message-ID: <5.2.1.1.0.20030608182810.0241c820@pop.bluewin.ch>

At 18:09 08.06.2003 +0200, Gerrit Holl wrote:
>Hi,
>
>Alex Martelli wrote:
> > >     if issubclass(typ, dict) and type(typ.__repr__) is 
> type(dict.__repr__):
> > >         # do stuff
> >
> > Aren't the calls to type() here wrong?  It seems to me that what you want
> > to check is just whether typ.__repr__ is dict.__repr__, not if the 
> types of
> > the two bound methods are the same.
>
>I was confused: I thought methods were dynamically created, but that is
>only true for bound methods, not for unbound methods. typ.__repr__ is
>dict.__repr__ is correct indeed.
>
>yours,
>Gerrit.

no it's true also for unbound methods but dict.__repr__ isn't either:

 >>> class C(object):
...   def f(self): pass
...
 >>> C.f is C.f
0
 >>> C.f
<unbound method C.f>
 >>> dict.__repr__
<slot wrapper '__repr__' of 'dict' objects>
 >>>

the problem is that the nature of dict.__repr__ is kind of an 
implementation  detail.

regards.





From guido@python.org  Mon Jun  9 01:52:04 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 08 Jun 2003 20:52:04 -0400
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: "Your message of 08 Jun 2003 09:01:40 +0200."
 <m3llwdvyqz.fsf@mira.informatik.hu-berlin.de>
References: <84FD9D85-9943-11D7-BD99-000A27B19B96@cwi.nl>
 <m3llwdvyqz.fsf@mira.informatik.hu-berlin.de>
Message-ID: <200306090052.h590q4M13147@pcp02138704pcs.reston01.va.comcast.net>

> I think the original motivation for the lib-tk subdirectory was the
> ability to add or remove it from sys.path, through
> Modules/Setup. These days, nobody edits Modules/Setup anymore, so I'd
> question its usefulness (it should be preserved for compatibility, of
> course).

Right.

> OTOH, I don't feel strongly about this, and would trust the decision
> in Kurt's hands.

I think it's okay if idlelib is in Lib, not in Lib/lib-tk.  It's
easier to find that way.

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


From Raymond Hettinger" <python@rcn.com  Mon Jun  9 05:43:42 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Mon, 9 Jun 2003 00:43:42 -0400
Subject: [Python-Dev] PEP-317
Message-ID: <001f01c32e41$b4b7c440$4827a044@oemcomputer>

I'm +0 on finally deprecating the string exceptions.
But am -1000 on eliminating implicit instantiation before Py3.0.

Right after writing:

 "In short, implicit instantiation has no advantages other than backwards
  compatibility ..."

I think it would only be fair to add:

  "If this proposal is adopted, nearly every piece of non-trivial python
   code that has ever been written would need to be revised or would
   fail to run.  Likewise, most tutorial and book examples would also
   fail."


Raymond Hettinger









From drifty@alum.berkeley.edu  Mon Jun  9 07:15:52 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Sun, 08 Jun 2003 23:15:52 -0700
Subject: [Python-Dev] PEP-317
In-Reply-To: <001f01c32e41$b4b7c440$4827a044@oemcomputer>
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer>
Message-ID: <3EE42618.2010007@ocf.berkeley.edu>

Raymond Hettinger wrote:
> I'm +0 on finally deprecating the string exceptions.
> But am -1000 on eliminating implicit instantiation before Py3.0.
> 

I am +1 on deprecating string exceptions for Python 3.

Now, since this will end up forcing instances to be created for each 
raised exception, can we now consider implementing chained exceptions as 
has been mentioned here numerous times?  Since we are going to end up 
breaking a good amount of code with this (if it happens) we might as 
well go all-out and get in the features we want.

-Brett



From greg@cosc.canterbury.ac.nz  Mon Jun  9 07:21:42 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 09 Jun 2003 18:21:42 +1200 (NZST)
Subject: [Python-Dev] PEP-317
In-Reply-To: <3EE42618.2010007@ocf.berkeley.edu>
Message-ID: <200306090621.h596LgF24277@oma.cosc.canterbury.ac.nz>

> can we now consider implementing chained exceptions as 
> has been mentioned here numerous times?

I must have missed that. What are chained exceptions?

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


From staschuk@telusplanet.net  Mon Jun  9 08:11:16 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Mon, 9 Jun 2003 01:11:16 -0600
Subject: [Python-Dev] PEP-317
In-Reply-To: <001f01c32e41$b4b7c440$4827a044@oemcomputer>; from raymond.hettinger@verizon.net on Mon, Jun 09, 2003 at 12:43:42AM -0400
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer>
Message-ID: <20030609011116.A1181@tibia.amotlpaa.bogus>

Quoth Raymond Hettinger:
  [...]
> But am -1000 on eliminating implicit instantiation before Py3.0.

The proposal is, in fact, to eliminate it in 3.0, and not before.
Is the PEP not clear on this point?

Btw, because I expect the implicit instantiation bit to be at
least somewhat controversial, I'd intended to have most of the
discussion on python-list.  (In fact, I just posted the PEP there,
before, sadly, noticing this thread.)  Should such discussion be
in py-dev instead?

  [...]
> I think it would only be fair to add:
> 
>   "If this proposal is adopted, nearly every piece of non-trivial python
>    code that has ever been written would need to be revised or would
>    fail to run.  Likewise, most tutorial and book examples would also
>    fail."

Yes, it's a massively backwards-incompatible change.  But I get
the feeling I'm missing the point you're making by emphasizing the
fact.

Is the point that you think readers of the PEP won't understand
the scope of the backwards-incompatibility, and so the point
deserves more emphasis?  I'd thought it was obvious.

Is the point that you think it's too backwards-incompatible to be
implemented as early as 3.0?  If so, I'd like to hear it
explicitly, and also your thoughts on what kind of schedule, if
any, seems more appropriate.

-- 
Steven Taschuk                           staschuk@telusplanet.net
"I'm always serious, never more so than when I'm being flippant."
                            -- _Look to Windward_, Iain M. Banks


From staschuk@telusplanet.net  Mon Jun  9 08:39:16 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Mon, 9 Jun 2003 01:39:16 -0600
Subject: [Python-Dev] PEP-317
In-Reply-To: <3EE42618.2010007@ocf.berkeley.edu>; from bac@OCF.Berkeley.EDU on Sun, Jun 08, 2003 at 11:15:52PM -0700
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <3EE42618.2010007@ocf.berkeley.edu>
Message-ID: <20030609013916.A1343@tibia.amotlpaa.bogus>

Quoth Brett C.:
  [...]
> I am +1 on deprecating string exceptions for Python 3.

PEP 317 actually proposes formally deprecating them in 2.4, and
eliminating them entirely in 3.0.  Are you +1 on that?

-- 
Steven Taschuk                            staschuk@telusplanet.net
"Our analysis begins with two outrageous benchmarks."
  -- "Implementation strategies for continuations", Clinger et al.


From ienj4nh0@hotmail.com  Mon Jun  9 17:53:48 2003
From: ienj4nh0@hotmail.com (Juliet Pool)
Date: Mon, 09 Jun 03 16:53:48 GMT
Subject: [Python-Dev] You are being watched...  swoz bza
Message-ID: <0o21-t$6a3zilfrx@jg4tr4x>

This is a multi-part message in MIME format.

--0E82B6FC_AA_1FBA.FB
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Protect Your Privacy NOW!

Did you know that government agencies are spying on
your computer? Hackers? Marketers? Etc.

We'll the latest program gets rid of all these sources
and protects you.

Avoid the following:

* Unwanted people/agencies on your computer
* Your computer keeping a incriminating log of what
you do
* Being traced by others online
* Slow Computer Speeds
* PLUS MUCH MORE!

Click below to Learn more and get your essential copy
today!


http://www.bestdealss.net/cgi-bin/kherefer.cgi/he/index008.html?MID=3Dkhe0=
08&r=3DTy8922



"Many employees remain unaware technology isn't
private. They may visit sexually explicit Web sites
and not realize their employer is watching, for
example. Many don't know messages can be retrieved
months later."

-- USA Today
















To be removed click below:
http://cythsia.com/auto/index.htm

 
vxfmaoubrl wzxh
ybbdnwwtgygrreribhxwycb z mm
--0E82B6FC_AA_1FBA.FB--



From y3nhamu2u6c7@netscape.com  Mon Jun  9 17:48:04 2003
From: y3nhamu2u6c7@netscape.com (Sergio Mcginnis)
Date: Mon, 09 Jun 03 16:48:04 GMT
Subject: [Python-Dev] Hi honey xeanrwarchqzdxp
Message-ID: <pl7yxd8b8v55--2$u@l2pstxnibbyl>

This is a multi-part message in MIME format.

--B74EDAF336EFE
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Protect Your Privacy NOW!

Did you know that government agencies are spying on
your computer? Hackers? Marketers? Etc.

We'll the latest program gets rid of all these sources
and protects you.

Avoid the following:

* Unwanted people/agencies on your computer
* Your computer keeping a incriminating log of what
you do
* Being traced by others online
* Slow Computer Speeds
* PLUS MUCH MORE!

Click below to Learn more and get your essential copy
today!


http://www.bestdealss.net/cgi-bin/kherefer.cgi/he/index008.html?MID=3Dkhe0=
08&r=3DNe1nn373





















To be removed click below:
http://cythsia.com/auto/index.htm

 
yd  exlnllvpilkwe r
l rgvopfksnca
bwgd fnxukr ykp l
n
evpat
 ihpqapduguqmkykq hntcpr

pqd lqpsp
--B74EDAF336EFE--



From mcherm@mcherm.com  Mon Jun  9 13:12:06 2003
From: mcherm@mcherm.com (Michael Chermside)
Date: Mon,  9 Jun 2003 05:12:06 -0700
Subject: [Python-Dev] RE: The Python interpreter is not fully thread-safe.
Message-ID: <1055160726.3ee4799638627@mcherm.com>

Tim Peters wrote:
> Under that meaning (which I believe Guido also had in mind when he wrote
> this section), Python's C API is indeed not thread-safe.  We don't have to
> apologize for that, though, we just have to spell out what's needed in the
> presence of threads.

Martin v. Löwis adds:
> This request was triggered by a question from c.l.p: "When will Python
> be thread-safe". It was not obvious that the poster was referring to
> the API docs, so the initial responses all were "Python *is* thread-safe".

Please note that what was confusing the the original poster was
almost certainly the docs saying that "Python" was not thread-safe
when what was really intended was, as Tim points out, that Python's 
C api was not thread safe. Using the term "free threading" is fine,
but also make it clear that it's the _C api_ we're talking about,
because Python itself (ie, programs coded in pure Python) _IS_ 
threadsafe.

-- Michael Chermside



From terry@wayforward.net  Mon Jun  9 14:10:03 2003
From: terry@wayforward.net (Terence Way)
Date: Mon, 9 Jun 2003 09:10:03 -0400
Subject: [Python-Dev] PEP-317
Message-ID: <AED28216-9A7B-11D7-BD8E-00039344A0EC@wayforward.net>

There is a rather pleasing symmetry between
     raise SomeClass, arg
and
     assert expr, arg

Is this intentional?  If so, should the assert form be deprecated as
well?



From tjreedy@udel.edu  Mon Jun  9 14:58:38 2003
From: tjreedy@udel.edu (Terry Reedy)
Date: Mon, 9 Jun 2003 09:58:38 -0400
Subject: [Python-Dev] Re: PEP-317
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer>
Message-ID: <bc23ln$v66$1@main.gmane.org>

"Raymond Hettinger" <raymond.hettinger@verizon.net> wrote in message
news:001f01c32e41$b4b7c440$4827a044@oemcomputer...
> I think it would only be fair to add:
>
>   "If this proposal is adopted, nearly every piece of non-trivial
python
>    code that has ever been written would need to be revised or would
>    fail to run.  Likewise, most tutorial and book examples would
also
>    fail."

A conversion utility that converted 'raise item' to 'raise item()' and
'raise item,arg' to 'raise item(arg)' would definitely be helpful.  A
working version, or at least a promise to produce one on acceptance
might make the PEP more palatable.

Terry J. Reedy





From aahz@pythoncraft.com  Mon Jun  9 14:59:14 2003
From: aahz@pythoncraft.com (Aahz)
Date: Mon, 9 Jun 2003 09:59:14 -0400
Subject: [Python-Dev] PEP-317
In-Reply-To: <20030609013916.A1343@tibia.amotlpaa.bogus>
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <3EE42618.2010007@ocf.berkeley.edu> <20030609013916.A1343@tibia.amotlpaa.bogus>
Message-ID: <20030609135914.GA27662@panix.com>

On Mon, Jun 09, 2003, Steven Taschuk wrote:
> Quoth Brett C.:
>>
>> I am +1 on deprecating string exceptions for Python 3.
> 
> PEP 317 actually proposes formally deprecating them in 2.4, and
> eliminating them entirely in 3.0.  Are you +1 on that?

Given how deeply embedded string exceptions are in Python, I believe
that we cannot afford to issue a DeprecationWarning until we start doing
the same for integer division.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From mwh@python.net  Mon Jun  9 15:05:07 2003
From: mwh@python.net (Michael Hudson)
Date: Mon, 09 Jun 2003 15:05:07 +0100
Subject: [Python-Dev] PEP-317
In-Reply-To: <20030609135914.GA27662@panix.com> (Aahz's message of "Mon, 9
 Jun 2003 09:59:14 -0400")
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer>
 <3EE42618.2010007@ocf.berkeley.edu>
 <20030609013916.A1343@tibia.amotlpaa.bogus>
 <20030609135914.GA27662@panix.com>
Message-ID: <2mr863gxd8.fsf@starship.python.net>

Aahz <aahz@pythoncraft.com> writes:

> On Mon, Jun 09, 2003, Steven Taschuk wrote:
>> Quoth Brett C.:
>>>
>>> I am +1 on deprecating string exceptions for Python 3.
>> 
>> PEP 317 actually proposes formally deprecating them in 2.4, and
>> eliminating them entirely in 3.0.  Are you +1 on that?
>
> Given how deeply embedded string exceptions are in Python, 

How deep is that?  'python -X' went away, causing no pain at all as
far as I could tell.

> I believe that we cannot afford to issue a DeprecationWarning until
> we start doing the same for integer division.

$ python -E -Wall
Python 2.3b1+ (#1, May  6 2003, 18:00:11) 
[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> raise "hello"
__main__:1: PendingDeprecationWarning: raising a string exception is deprecated
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
hello

We don't seem to do that for integer division yet.

Cheers,
M.

-- 
  incidentally, asking why things are "left out of the language" is
  a good sign that the asker is fairly clueless.
                                        -- Erik Naggum, comp.lang.lisp


From guido@python.org  Mon Jun  9 15:27:08 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 09 Jun 2003 10:27:08 -0400
Subject: [Python-Dev] PEP-317
In-Reply-To: Your message of "Mon, 09 Jun 2003 09:59:14 EDT."
 <20030609135914.GA27662@panix.com>
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <3EE42618.2010007@ocf.berkeley.edu> <20030609013916.A1343@tibia.amotlpaa.bogus>
 <20030609135914.GA27662@panix.com>
Message-ID: <200306091427.h59ER8j04188@odiug.zope.com>

> >> I am +1 on deprecating string exceptions for Python 3.

Python 3 will not have string exceptions.

> > PEP 317 actually proposes formally deprecating them in 2.4, and
> > eliminating them entirely in 3.0.  Are you +1 on that?
> 
> Given how deeply embedded string exceptions are in Python, I believe
> that we cannot afford to issue a DeprecationWarning until we start doing
> the same for integer division.

I don't see a reason to tie these two events together, but I agree
that 2.4 is probably too early to start being noisy about string
exceptions.  Nevertheless they should be deprecated in all docs.

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


From pedronis@bluewin.ch  Mon Jun  9 15:27:46 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Mon, 09 Jun 2003 16:27:46 +0200
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <bc23ln$v66$1@main.gmane.org>
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer>
Message-ID: <5.2.1.1.0.20030609162121.02470d70@pop.bluewin.ch>

At 09:58 09.06.2003 -0400, Terry Reedy wrote:

>"Raymond Hettinger" <raymond.hettinger@verizon.net> wrote in message
>news:001f01c32e41$b4b7c440$4827a044@oemcomputer...
> > I think it would only be fair to add:
> >
> >   "If this proposal is adopted, nearly every piece of non-trivial
>python
> >    code that has ever been written would need to be revised or would
> >    fail to run.  Likewise, most tutorial and book examples would
>also
> >    fail."
>
>A conversion utility that converted 'raise item' to 'raise item()' and
>'raise item,arg' to 'raise item(arg)' would definitely be helpful.  A
>working version, or at least a promise to produce one on acceptance
>might make the PEP more palatable.

given that in:

raise X
raise X,y
raise X(...)

(likely) in most cases X is a builtin/global constant/or comes straight 
from an import, such a static analysis tool should be doable, for the rest 
the user could be informed about non-straightforward cases like:

def raise_(X,y):
   raise X,y

regards. 



From aahz@pythoncraft.com  Mon Jun  9 15:30:26 2003
From: aahz@pythoncraft.com (Aahz)
Date: Mon, 9 Jun 2003 10:30:26 -0400
Subject: [Python-Dev] PEP-317
In-Reply-To: <2mr863gxd8.fsf@starship.python.net>
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <3EE42618.2010007@ocf.berkeley.edu> <20030609013916.A1343@tibia.amotlpaa.bogus> <20030609135914.GA27662@panix.com> <2mr863gxd8.fsf@starship.python.net>
Message-ID: <20030609143026.GA3293@panix.com>

On Mon, Jun 09, 2003, Michael Hudson wrote:
> Aahz <aahz@pythoncraft.com> writes:
>> On Mon, Jun 09, 2003, Steven Taschuk wrote:
>>> Quoth Brett C.:
>>>>
>>>> I am +1 on deprecating string exceptions for Python 3.
>>> 
>>> PEP 317 actually proposes formally deprecating them in 2.4, and
>>> eliminating them entirely in 3.0.  Are you +1 on that?
>>
>> Given how deeply embedded string exceptions are in Python, 
> 
> How deep is that?  'python -X' went away, causing no pain at all as
> far as I could tell.

Well, I was still casually using string exceptions up until about a year
ago, and I think I'm not the only one.  There's probably lots of pre-2.0
code still running in the wild with string exceptions.

>> I believe that we cannot afford to issue a DeprecationWarning until
>> we start doing the same for integer division.
> 
> $ python -E -Wall
> Python 2.3b1+ (#1, May  6 2003, 18:00:11) 
> [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> raise "hello"
> __main__:1: PendingDeprecationWarning: raising a string exception is deprecated
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> hello
> 
> We don't seem to do that for integer division yet.

Correct.  Note that I said "Deprecation", not "PendingDeprecation".  If
we're just going to use PendingDeprecation, I'm fine with that in 2.4.
Seems to me that both integers and string exceptions require
line-by-line analysis to correct, and I think it's unfair to shove
people to do that work twice.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From pedronis@bluewin.ch  Mon Jun  9 15:35:55 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Mon, 09 Jun 2003 16:35:55 +0200
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <5.2.1.1.0.20030609162121.02470d70@pop.bluewin.ch>
References: <bc23ln$v66$1@main.gmane.org>
 <001f01c32e41$b4b7c440$4827a044@oemcomputer>
Message-ID: <5.2.1.1.0.20030609163436.02470d70@pop.bluewin.ch>

At 16:27 09.06.2003 +0200, Samuele Pedroni wrote:
>At 09:58 09.06.2003 -0400, Terry Reedy wrote:
>
>>"Raymond Hettinger" <raymond.hettinger@verizon.net> wrote in message
>>news:001f01c32e41$b4b7c440$4827a044@oemcomputer...
>> > I think it would only be fair to add:
>> >
>> >   "If this proposal is adopted, nearly every piece of non-trivial
>>python
>> >    code that has ever been written would need to be revised or would
>> >    fail to run.  Likewise, most tutorial and book examples would
>>also
>> >    fail."
>>
>>A conversion utility that converted 'raise item' to 'raise item()' and
>>'raise item,arg' to 'raise item(arg)' would definitely be helpful.  A
>>working version, or at least a promise to produce one on acceptance
>>might make the PEP more palatable.
>
>given that in:
>
>raise X
>raise X,y
>raise X(...)
>
>(likely) in most cases X is a builtin/global constant/or comes straight 
>from an import, such a static analysis tool should be doable, for the rest 
>the user could be informed about non-straightforward cases like:
>
>def raise_(X,y):
>   raise X,y


the point: such a tool could also statically detect string exceptions 
usage, I think PyChecker already is able of that. 



From rmunn@pobox.com  Mon Jun  9 15:36:46 2003
From: rmunn@pobox.com (Robin Munn)
Date: Mon, 9 Jun 2003 09:36:46 -0500
Subject: [Python-Dev] python-dev Summary for 2003-05-16 through 2003-05-31
In-Reply-To: <3EE2749C.4050205@ocf.berkeley.edu>
References: <3EE2749C.4050205@ocf.berkeley.edu>
Message-ID: <20030609143646.GA3272@rmunnlfs>

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 07, 2003 at 04:26:20PM -0700, Brett C. wrote:
> Here is the rough of the summary, as usual.  I will not send it out any=
=20
> earlier than Tuesday.
>=20
> -------------------------

[snip]

> `Python 2.2.3`_ has gone out the door!
>=20
> .. _Python 2.2.3: http://www.python.org./2.2.3/

You've got a typo in that URL: an extra trailing dot after the ".org".

Other than that, nice job once again. I haven't finished reading the
summary, so it's possible I'll find something else, but it looks
excellent so far.

*poof*! Robin disappears back into lurking mode...

--=20
Robin Munn <rmunn@pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838    50FF 2478 CFFB 081A 8338  54F7 845D ACFD 6AFB 6838

--J/dobhs11T7y2rNN
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+5Jt+hF2s/Wr7aDgRAtIoAJ9uOAGjqt8Xj7ag+DEwTDrhuSN40ACfY+5r
w8lXc6mvcn86tjNsJg2/irY=
=0nbo
-----END PGP SIGNATURE-----

--J/dobhs11T7y2rNN--


From guido@python.org  Mon Jun  9 15:40:04 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 09 Jun 2003 10:40:04 -0400
Subject: [Python-Dev] PEP-317
In-Reply-To: Your message of "Mon, 09 Jun 2003 10:30:26 EDT."
 <20030609143026.GA3293@panix.com>
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <3EE42618.2010007@ocf.berkeley.edu> <20030609013916.A1343@tibia.amotlpaa.bogus> <20030609135914.GA27662@panix.com> <2mr863gxd8.fsf@starship.python.net>
 <20030609143026.GA3293@panix.com>
Message-ID: <200306091440.h59Ee4m04273@odiug.zope.com>

> Well, I was still casually using string exceptions up until about a year
> ago, and I think I'm not the only one.  There's probably lots of pre-2.0
> code still running in the wild with string exceptions.

Note "casually", probably in throw-away code.  If you knew they didn't
exist, you'd "casually" use some built-in exception, e.g. RuntimeError.

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


From neal@metaslash.com  Mon Jun  9 15:51:31 2003
From: neal@metaslash.com (Neal Norwitz)
Date: Mon, 09 Jun 2003 10:51:31 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <5.2.1.1.0.20030609163436.02470d70@pop.bluewin.ch>
References: <bc23ln$v66$1@main.gmane.org>
 <001f01c32e41$b4b7c440$4827a044@oemcomputer>
 <5.2.1.1.0.20030609163436.02470d70@pop.bluewin.ch>
Message-ID: <20030609145131.GA20606@epoch.metaslash.com>

On Mon, Jun 09, 2003 at 04:35:55PM +0200, Samuele Pedroni wrote:
> At 16:27 09.06.2003 +0200, Samuele Pedroni wrote:
> >At 09:58 09.06.2003 -0400, Terry Reedy wrote:
> >
> >>A conversion utility that converted 'raise item' to 'raise item()' and
> >>'raise item,arg' to 'raise item(arg)' would definitely be helpful.  A
> >>working version, or at least a promise to produce one on acceptance
> >>might make the PEP more palatable.
> >
> >given that in:
> >
> >raise X
> >raise X,y
> >raise X(...)
> >
> >(likely) in most cases X is a builtin/global constant/or comes straight 
> >from an import, such a static analysis tool should be doable, for the rest 
> >the user could be informed about non-straightforward cases like:
> >
> >def raise_(X,y):
> >  raise X,y
> 
> 
> the point: such a tool could also statically detect string exceptions 
> usage, I think PyChecker already is able of that. 

Yes, it does.  PyChecker could be modified to check for 'raise item'
vs. 'raise item()' too.  

I'm all for removing string exceptions, but -1 on the PEP.  I don't
see the benefit.  It seems to require more keystrokes for at best 
a very small conceptual benefit.

BTW, this may be more parallel to Java, but not C++.  How about Ruby?
Just curious...

Neal



From patmiller@llnl.gov  Mon Jun  9 16:03:17 2003
From: patmiller@llnl.gov (Pat Miller)
Date: Mon, 09 Jun 2003 08:03:17 -0700
Subject: [Python-Dev] PEP-317
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <3EE42618.2010007@ocf.berkeley.edu> <20030609013916.A1343@tibia.amotlpaa.bogus> <20030609135914.GA27662@panix.com> <2mr863gxd8.fsf@starship.python.net>              <20030609143026.GA3293@panix.com> <200306091440.h59Ee4m04273@odiug.zope.com>
Message-ID: <3EE4A1B5.2090101@llnl.gov>

> Well, I was still casually using string exceptions up until about a year
>> ago, and I think I'm not the only one.  There's probably lots of pre-2.0
>> code still running in the wild with string exceptions.
> 
> Note "casually", probably in throw-away code.  If you knew they didn't
> exist, you'd "casually" use some built-in exception, e.g. RuntimeError.

I'm mostly with Guido on this however...  I would venture that many of
these "wild" string raises are shortcut error messages.  Is there really
a lot of code that does < try:  catch "foo": > ?

I still "casually" use string exceptions mostly as a shortcut to get
unfinished code to bomb (or to generate a quick traceback.  Often of the form

if foo.is_simple():
    foo.easy()
else:
    raise 'zz'


Granted, I could probably use

raise NotImplementedError

But that is more typing than I want for a quick line that will likely
be ripped out the first time it actually triggers.

Also, I sometimes trap NotImplementedError, so I want an exception that
I would never try to catch (I don't think I could stomach a except "zz":
line in my code :-).

The good news for me (and I suspect many other casual string throwers)
is that if < raise "zz" > raises ANY runtime exception, most of my
code will continue to "do the right thing."

Pat

-- 
Patrick Miller | (925) 423-0309 | http://www.llnl.gov/CASC/people/pmiller

Be the change you want to see in the world.
  -- Mahatma Gandhi (1869-1948)



From tim.one@comcast.net  Mon Jun  9 16:28:12 2003
From: tim.one@comcast.net (Tim Peters)
Date: Mon, 09 Jun 2003 11:28:12 -0400
Subject: [Python-Dev] PEP-317
In-Reply-To: <AED28216-9A7B-11D7-BD8E-00039344A0EC@wayforward.net>
Message-ID: <BIEJKCLHCIOIHAGOKOLHAEPIFNAA.tim.one@comcast.net>

[Terence Way]
> There is a rather pleasing symmetry between
>      raise SomeClass, arg
> and
>      assert expr, arg
>
> Is this intentional?  If so, should the assert form be deprecated as
> well?

The symmetry is purely syntactic, and is misleading:  assert is a control
structure, and doesn't evaluate "arg" unless the runtime value of expr is
false.  For example,

>>> assert True, 1/0
>>> assert False, 1/0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ZeroDivisionError: integer division or modulo by zero
>>>

raise always evaluates its arg.



From skip@pobox.com  Mon Jun  9 16:49:08 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 9 Jun 2003 10:49:08 -0500
Subject: [Python-Dev] python-dev Summary for 2003-05-16 through 2003-05-31
In-Reply-To: <20030609143646.GA3272@rmunnlfs>
References: <3EE2749C.4050205@ocf.berkeley.edu>
 <20030609143646.GA3272@rmunnlfs>
Message-ID: <16100.44148.845519.289401@montanaro.dyndns.org>

    >> .. _Python 2.2.3: http://www.python.org./2.2.3/

    Robin> You've got a typo in that URL: an extra trailing dot after the
    Robin> ".org".

Typo perhaps, but it is still a valid name (a trailing dot makes the name
absolute, much the same way that a leading / makes a Unix path name
absolute).  If your web browser or email client doesn't grok that (Apple's
Safari handled it just fine), I'd report it as a bug. ;-)

Skip


From staschuk@telusplanet.net  Mon Jun  9 18:18:54 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Mon, 9 Jun 2003 11:18:54 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <bc23ln$v66$1@main.gmane.org>; from tjreedy@udel.edu on Mon, Jun 09, 2003 at 09:58:38AM -0400
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <bc23ln$v66$1@main.gmane.org>
Message-ID: <20030609111854.A1209@tibia.amotlpaa.bogus>

Quoth Terry Reedy:
  [...]
> A conversion utility that converted 'raise item' to 'raise item()' and
> 'raise item,arg' to 'raise item(arg)' would definitely be helpful.  A
> working version, or at least a promise to produce one on acceptance
> might make the PEP more palatable.

I do intend to write such a tool.

I'd imagined that, being PEP champion, I would be the obvious
person to produce the relevant patches to the standard library.
There are more than a thousand raise statements there, mostly of
the implicitly instantiating type, so you can bet I'm not doing it
by hand if I can avoid it.

-- 
Steven Taschuk                               staschuk@telusplanet.net
"[T]rue greatness is when your name is like ampere, watt, and fourier
 -- when it's spelled with a lower case letter."      -- R.W. Hamming


From staschuk@telusplanet.net  Mon Jun  9 18:23:06 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Mon, 9 Jun 2003 11:23:06 -0600
Subject: [Python-Dev] PEP-317
In-Reply-To: <AED28216-9A7B-11D7-BD8E-00039344A0EC@wayforward.net>; from terry@wayforward.net on Mon, Jun 09, 2003 at 09:10:03AM -0400
References: <AED28216-9A7B-11D7-BD8E-00039344A0EC@wayforward.net>
Message-ID: <20030609112306.B1209@tibia.amotlpaa.bogus>

Quoth Terence Way:
> There is a rather pleasing symmetry between
>      raise SomeClass, arg
> and
>      assert expr, arg
> 
> Is this intentional?  If so, should the assert form be deprecated as
> well?

I don't see why.  Certainly none of the PEP's arguments against
the raise syntax apply at all to assert.

-- 
Steven Taschuk                staschuk@telusplanet.net
"I tried to be pleasant and accommodating, but my head
 began to hurt from his banality."   -- _Seven_ (1996)


From python@rcn.com  Mon Jun  9 18:47:43 2003
From: python@rcn.com (Raymond Hettinger)
Date: Mon, 9 Jun 2003 13:47:43 -0400
Subject: [Python-Dev] Re: PEP-317
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <bc23ln$v66$1@main.gmane.org> <20030609111854.A1209@tibia.amotlpaa.bogus>
Message-ID: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>

> Quoth Terry Reedy:
>   [...]
> > A conversion utility that converted 'raise item' to 'raise item()' and
> > 'raise item,arg' to 'raise item(arg)' would definitely be helpful.  A
> > working version, or at least a promise to produce one on acceptance
> > might make the PEP more palatable.
> 
> I do intend to write such a tool.
> 
> I'd imagined that, being PEP champion, I would be the obvious
> person to produce the relevant patches to the standard library.
> There are more than a thousand raise statements there, mostly of
> the implicitly instantiating type, so you can bet I'm not doing it
> by hand if I can avoid it.

PEP-290 advises against automated tools for this type of change.
Every line of code needs to be read and understood before
changing it.  Then, each change should be reviewed.  It's the only 
way to make sure you're not introducing mindless cut and paste 
errors throughout the code.  It is for this reason that I've spent
more than one weekend reviewing every line of Walter's code
updates -- he does them by hand and has less than a 2% error rate.

Also, take a look at what would need to be done to the test suite.
The changes there are less amenable to an automated update.

Grep could find most potential changes but I don't see how 
you can statically determine whether 'raise x'
is a class or instance without running the code.

That brings up the question of whether the warnings are a 
runtime or compile time event.  Can you always determine
at compile time whether raise Class is being used?  If not,
the performance penalty for the warnings module is something
else to consider.

Except for conceptual purity, is there any real payoff in terms
of performance or capability that would warrant a wholesale
revision of working code?



Raymond Hettinger

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################


From staschuk@telusplanet.net  Mon Jun  9 19:51:47 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Mon, 9 Jun 2003 12:51:47 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>; from python@rcn.com on Mon, Jun 09, 2003 at 01:47:43PM -0400
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <bc23ln$v66$1@main.gmane.org> <20030609111854.A1209@tibia.amotlpaa.bogus> <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
Message-ID: <20030609125147.F1359@tibia.amotlpaa.bogus>

Quoth Raymond Hettinger:
  [...]
> That brings up the question of whether the warnings are a 
> runtime or compile time event.  Can you always determine
> at compile time whether raise Class is being used?  If not,
> the performance penalty for the warnings module is something
> else to consider.

As the PEP says, the warning about using three arguments is issued
at compile-time, while the others are at run-time, in keeping with
when the corresponding future errors would occur.

The performance penalty of the warnings is a legitimate concern,
but I don't expect it to be a serious problem:

1. The compile-time warning is, well, issued at compile time,
which is not usually on a performance-critical path.

2. The run-time warnings are issued when raising an exception;
also not usually on a performance-critical path.  (Except for
things like StopIteration.  But the PEP does not propose any
change to the C API, so the built-in iterators won't be affected.)

-- 
Steven Taschuk                                     staschuk@telusplanet.net
Receive them ignorant; dispatch them confused.  (Weschler's Teaching Motto)


From staschuk@telusplanet.net  Mon Jun  9 19:54:37 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Mon, 9 Jun 2003 12:54:37 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>; from python@rcn.com on Mon, Jun 09, 2003 at 01:47:43PM -0400
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <bc23ln$v66$1@main.gmane.org> <20030609111854.A1209@tibia.amotlpaa.bogus> <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
Message-ID: <20030609125437.G1359@tibia.amotlpaa.bogus>

Quoth Raymond Hettinger:
  [...]
> Except for conceptual purity, is there any real payoff in terms
> of performance or capability that would warrant a wholesale
> revision of working code?

There's also the question (mentioned in the PEP, albeit
parenthetically) of how implicit instantiation could work with any
future plan to allow new-style exceptions.  This point is also
being discussed in the thread on c.l.py; shall we adjourn there?

-- 
Steven Taschuk                             staschuk@telusplanet.net
"I may be wrong but I'm positive."  -- _Friday_, Robert A. Heinlein


From staschuk@telusplanet.net  Mon Jun  9 19:51:21 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Mon, 9 Jun 2003 12:51:21 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>; from python@rcn.com on Mon, Jun 09, 2003 at 01:47:43PM -0400
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer> <bc23ln$v66$1@main.gmane.org> <20030609111854.A1209@tibia.amotlpaa.bogus> <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
Message-ID: <20030609125121.E1359@tibia.amotlpaa.bogus>

Quoth Raymond Hettinger:
  [...]
> PEP-290 advises against automated tools for this type of change.

I certainly agree to the need for human review of such changes.  I
don't think this would be onerous, though (as you've suggested in
private email) I should certainly try it myself.

  [...]
> Also, take a look at what would need to be done to the test suite.
> The changes there are less amenable to an automated update.

I will.

> Grep could find most potential changes but I don't see how 
> you can statically determine whether 'raise x'
> is a class or instance without running the code.

That's true.  Certain cases of two- and three- argument raise
statements are difficult as well.

Rather than discuss it in the abstract, how about I just implement
the tool I have in mind and see how well it works?

  [...]
-- 
Steven Taschuk    staschuk@telusplanet.net
"Tomorrow never happens."  -- Janis Joplin


From pje@telecommunity.com  Mon Jun  9 19:52:18 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Mon, 09 Jun 2003 14:52:18 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <20030609125437.G1359@tibia.amotlpaa.bogus>
References: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
 <001f01c32e41$b4b7c440$4827a044@oemcomputer>
 <bc23ln$v66$1@main.gmane.org>
 <20030609111854.A1209@tibia.amotlpaa.bogus>
 <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
Message-ID: <5.1.1.6.0.20030609145000.00a53380@telecommunity.com>

At 12:54 PM 6/9/03 -0600, Steven Taschuk wrote:
>Quoth Raymond Hettinger:
>   [...]
> > Except for conceptual purity, is there any real payoff in terms
> > of performance or capability that would warrant a wholesale
> > revision of working code?
>
>There's also the question (mentioned in the PEP, albeit
>parenthetically) of how implicit instantiation could work with any
>future plan to allow new-style exceptions.

isinstance(ob,Exception)
issubclass(cls,Exception)

That is, a new-style exception would have to be an instance or subclass of 
Exception.

The *real* thing that's broken is the check to see if an exception is a 
tuple!  isinstance(ob,Exception) should be checked first.

I guess I'm missing why this wouldn't work for new-style exceptions, 
provided they are required to subclass Exception (which I thought 
everything was going to be required to do eventually).



From guido@python.org  Mon Jun  9 20:03:08 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 09 Jun 2003 15:03:08 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: Your message of "Mon, 09 Jun 2003 14:52:18 EDT."
 <5.1.1.6.0.20030609145000.00a53380@telecommunity.com>
References: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer> <001f01c32e41$b4b7c440$4827a044@oemcomputer> <bc23ln$v66$1@main.gmane.org> <20030609111854.A1209@tibia.amotlpaa.bogus> <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
 <5.1.1.6.0.20030609145000.00a53380@telecommunity.com>
Message-ID: <200306091903.h59J38Y09921@odiug.zope.com>

> I guess I'm missing why this wouldn't work for new-style exceptions, 
> provided they are required to subclass Exception (which I thought 
> everything was going to be required to do eventually).

I'm dithering on that, actually.  It's a Java vs. C++ thing: in C++
you can raise any type, in Java it must be an Exception instance.

Python usually doesn't care about isinstance relationships but cares
about whether the needed protocol is implemented, and this suggests
that requiring exceptions to subclass Exception is unPythonic.

But at other times, the desire to catch bogus arguments to raise
suggests that the subclass requirement might be just fine, and I don't
have a use case that breaks with this requirement (since you can
always use multiple inheritance to make a desirable class raisable).

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


From fdrake@acm.org  Mon Jun  9 20:07:16 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon, 9 Jun 2003 15:07:16 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306091903.h59J38Y09921@odiug.zope.com>
References: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
 <001f01c32e41$b4b7c440$4827a044@oemcomputer>
 <bc23ln$v66$1@main.gmane.org>
 <20030609111854.A1209@tibia.amotlpaa.bogus>
 <5.1.1.6.0.20030609145000.00a53380@telecommunity.com>
 <200306091903.h59J38Y09921@odiug.zope.com>
Message-ID: <16100.56036.766261.229999@grendel.zope.com>

Guido van Rossum writes:
 > Python usually doesn't care about isinstance relationships but cares
 > about whether the needed protocol is implemented, and this suggests
 > that requiring exceptions to subclass Exception is unPythonic.

Definiately!

 > But at other times, the desire to catch bogus arguments to raise
 > suggests that the subclass requirement might be just fine, and I don't
 > have a use case that breaks with this requirement (since you can
 > always use multiple inheritance to make a desirable class raisable).

Yeah, but that's really annoying.


  -Fred

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


From pje@telecommunity.com  Mon Jun  9 20:10:32 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Mon, 09 Jun 2003 15:10:32 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306091903.h59J38Y09921@odiug.zope.com>
References: <Your message of "Mon, 09 Jun 2003 14:52:18 EDT." <5.1.1.6.0.20030609145000.00a53380@telecommunity.com>
 <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
 <001f01c32e41$b4b7c440$4827a044@oemcomputer>
 <bc23ln$v66$1@main.gmane.org>
 <20030609111854.A1209@tibia.amotlpaa.bogus>
 <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
 <5.1.1.6.0.20030609145000.00a53380@telecommunity.com>
Message-ID: <5.1.1.6.0.20030609150523.00a53630@telecommunity.com>

At 03:03 PM 6/9/03 -0400, Guido van Rossum wrote:
> > I guess I'm missing why this wouldn't work for new-style exceptions,
> > provided they are required to subclass Exception (which I thought
> > everything was going to be required to do eventually).
>
>I'm dithering on that, actually.  It's a Java vs. C++ thing: in C++
>you can raise any type, in Java it must be an Exception instance.
>
>Python usually doesn't care about isinstance relationships but cares
>about whether the needed protocol is implemented, and this suggests
>that requiring exceptions to subclass Exception is unPythonic.

Hm.  I suppose if we had PEP 246 in the core, we could always 
'adapt(ob,Exception)' instead, and also define an adaptation for tuples to 
become exceptions.  ;)


>But at other times, the desire to catch bogus arguments to raise
>suggests that the subclass requirement might be just fine, and I don't
>have a use case that breaks with this requirement (since you can
>always use multiple inheritance to make a desirable class raisable).

And I expect that even Jim Fulton won't argue that a subclass of an 
Exception subclass should be able to change its stripes and *not* be usable 
as an Exception any more.  In other words, I don't think it's any more of a 
wart than requiring someone to subclass datetime.tzinfo.



From nas@python.ca  Mon Jun  9 20:18:21 2003
From: nas@python.ca (Neil Schemenauer)
Date: Mon, 9 Jun 2003 12:18:21 -0700
Subject: [Python-Dev] towards a faster Python
Message-ID: <20030609191821.GA22026@glacier.arctrix.com>

Hi guys,

With Guido's blessing, I just commited a change that takes a small step
towards where we want to be, IMO.  Using __setattr__ on a module to
create a global name that shadows a builtin name now raises a
DeprecationWarning.  E.g.

    import fileinput
    fileinput.open = 10 # <- warning will be raised

The goal is that the compiler should be able to determine the scope of a
name at compile time.  Code like the above does not allow that and so
non-local names must be searched for in both globals and builtins at run
time.  Unfortunately the warning is not bulletproof.  It's possible to
modify the module dict directly and bypass the warning.  I'm not sure
what to do about that. :-(

Eventually we might want to allow optimizations based on known builtin
functions.  For example, code like

    for i in range(100000):
        ...

could be rewritten to use an integer counter rather than creating a list
and then iterating over it.  I'm not sure how much resistance there
would be in the community to disallowing reassignment of builtin names
though.  I don't think I've ever reassigned a builtin name so I think it
would be worth it.

The compiler could also warn about references to non-existent names.
That's a common error and would be helpful to developers.

Looking farther into the future, knowing that a name refers to a
specific builtin function would give a type inference system a lot more
information to work with.  I guess it would help Psyco.

Just some ideas to think about.

   Neil


From staschuk@telusplanet.net  Mon Jun  9 20:30:36 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Mon, 9 Jun 2003 13:30:36 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306091903.h59J38Y09921@odiug.zope.com>; from guido@python.org on Mon, Jun 09, 2003 at 03:03:08PM -0400
References: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer> <001f01c32e41$b4b7c440$4827a044@oemcomputer> <bc23ln$v66$1@main.gmane.org> <20030609111854.A1209@tibia.amotlpaa.bogus> <003201c32eaf$3b02ce60$8fb5958d@oemcomputer> <5.1.1.6.0.20030609145000.00a53380@telecommunity.com> <200306091903.h59J38Y09921@odiug.zope.com>
Message-ID: <20030609133036.J1359@tibia.amotlpaa.bogus>

Quoth Guido van Rossum:
  [...]
> Python usually doesn't care about isinstance relationships but cares
> about whether the needed protocol is implemented, and this suggests
> that requiring exceptions to subclass Exception is unPythonic.

This came up in python-list not long ago [1], and I raised (heh)
exactly that argument.  Alex Martelli counterargued that
exceptions are one area in which we *do* usually care about
isinstance relationships, since that's how we specify which
exceptions to catch.

[1] http://mail.python.org/pipermail/python-list/2003-May/160965.html

-- 
Steven Taschuk                           staschuk@telusplanet.net
"I'm always serious, never more so than when I'm being flippant."
                            -- _Look to Windward_, Iain M. Banks


From guido@python.org  Mon Jun  9 20:26:46 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 09 Jun 2003 15:26:46 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: Your message of "Mon, 09 Jun 2003 13:30:36 MDT."
 <20030609133036.J1359@tibia.amotlpaa.bogus>
References: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer> <001f01c32e41$b4b7c440$4827a044@oemcomputer> <bc23ln$v66$1@main.gmane.org> <20030609111854.A1209@tibia.amotlpaa.bogus> <003201c32eaf$3b02ce60$8fb5958d@oemcomputer> <5.1.1.6.0.20030609145000.00a53380@telecommunity.com> <200306091903.h59J38Y09921@odiug.zope.com>
 <20030609133036.J1359@tibia.amotlpaa.bogus>
Message-ID: <200306091926.h59JQkW10114@odiug.zope.com>

> Quoth Guido van Rossum:
>   [...]
> > Python usually doesn't care about isinstance relationships but cares
> > about whether the needed protocol is implemented, and this suggests
> > that requiring exceptions to subclass Exception is unPythonic.

[Steven T]
> This came up in python-list not long ago [1], and I raised (heh)
> exactly that argument.  Alex Martelli counterargued that
> exceptions are one area in which we *do* usually care about
> isinstance relationships, since that's how we specify which
> exceptions to catch.
> 
> [1] http://mail.python.org/pipermail/python-list/2003-May/160965.html

Excellent argument.  Thanks, Steve and Alex.

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


From pedronis@bluewin.ch  Mon Jun  9 20:30:07 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Mon, 09 Jun 2003 21:30:07 +0200
Subject: [Python-Dev] On Syntax Extensibility (again)
In-Reply-To: <5.2.1.1.0.20030607010809.02434e68@pop.bluewin.ch>
Message-ID: <5.2.1.1.0.20030609204030.0248cb50@pop.bluewin.ch>

still thinking about this stuff.

At 01:19 07.06.2003 +0200, Samuele Pedroni wrote:
>I thought python-dev archives would be a better place for this than my hd. 
>Warning: terse.
>
>I have come to the conclusion that I should agree with Guido:
>
>- generators do not let really abstract over things like exception 
>handling etc.

what I had in mind were generators like this one:

def all_lines(file_list_filename):
   for fn in open(file_list_filename,'r'):
     fn = fn.rstrip()
     for line in open(fn,'r'):
       yield line

for line in all_lines("all_files"):
   <do-stuff>

what if we want to release resources (here in this toy example namely close 
files) in a timely fashion in face of exception also in <do-stuff>.

all of these touch on the issue:
- non-support of 'yield' inside try-finally
- PEP 288: Generators Attributes and Exceptions
- PEP 310: Reliable Acquisition/Release Pairs
- proposals for syntax extensibility through Ruby/Smalltalk-like 
first-class blocks

so all these proposals should be considered together and in an organic way.

With current Python a possible rewrite of the above would be:

class all_lines(object):
   def __init__(self,file_list_fname):
     self.listf = open(file_list_fname,'r')
     self.f = None
   def __iter__(self):
     for fn in self.listf:
       fn = fn.rstrip()
       self.f = open(fn,'r')
       for line in self.f:
         yield line
       self.f.close()
       self.f = None
   def close(self):
     self.listf.close()
     if self.f: self.f.close()

x = all_lines("all_files")
try:
   for line in x:
     <do-stuff>
finally:
   x.close()

kind of obfuscated.

maybe-generators-should-grow-a-close-method-ly y'rs - Samuele 



From drifty@alum.berkeley.edu  Mon Jun  9 20:41:42 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Mon, 09 Jun 2003 12:41:42 -0700
Subject: [Python-Dev] PEP-317
In-Reply-To: <200306090621.h596LgF24277@oma.cosc.canterbury.ac.nz>
References: <200306090621.h596LgF24277@oma.cosc.canterbury.ac.nz>
Message-ID: <3EE4E2F6.2050403@ocf.berkeley.edu>

Greg Ewing wrote:
>>can we now consider implementing chained exceptions as 
>>has been mentioned here numerous times?
> 
> 
> I must have missed that. What are chained exceptions?
> 

It was brought up once that raising an exception after another exception 
was already raised (because of an error in the exception-handling code, 
raising another exception to change the meaning) causes the original 
exception to be ignored.  It was suggested to keep a reference to the 
previous exception in the current exception so you could know about all 
the exceptions that have been raised.

Implementation could be easy as adding an attribute to store a reference 
to any previous exception that someone can look at if they care to. 
Obviously the reference would be set automatically when an exception is 
raised and an exception is already pending.

I think the open question was whether 'except' clauses should also check 
the previous exceptions or only the current one.

This was discussed on the list between Ping and I think Walter (could be 
wrong about Walter but I know Ping was involved).  Should be in the 
Summary archive somewhere; just need to find it.  =)

-Brett



From drifty@alum.berkeley.edu  Mon Jun  9 20:51:44 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Mon, 09 Jun 2003 12:51:44 -0700
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <20030609191821.GA22026@glacier.arctrix.com>
References: <20030609191821.GA22026@glacier.arctrix.com>
Message-ID: <3EE4E550.2070407@ocf.berkeley.edu>

Neil Schemenauer wrote:
> Hi guys,
> 
> With Guido's blessing, I just commited a change that takes a small step
> towards where we want to be, IMO.  Using __setattr__ on a module to
> create a global name that shadows a builtin name now raises a
> DeprecationWarning.  E.g.
> 
>     import fileinput
>     fileinput.open = 10 # <- warning will be raised
> 
> The goal is that the compiler should be able to determine the scope of a
> name at compile time.  Code like the above does not allow that and so
> non-local names must be searched for in both globals and builtins at run
> time.  

Spiffy.

> Unfortunately the warning is not bulletproof.  It's possible to
> modify the module dict directly and bypass the warning.  I'm not sure
> what to do about that. :-(
> 

Probably only way to deal with that would to come up with namespace 
dicts that can restrictions set on them?

> Eventually we might want to allow optimizations based on known builtin
> functions.  For example, code like
> 
>     for i in range(100000):
>         ...
> 
> could be rewritten to use an integer counter rather than creating a list
> and then iterating over it.  I'm not sure how much resistance there
> would be in the community to disallowing reassignment of builtin names
> though.  I don't think I've ever reassigned a builtin name so I think it
> would be worth it.
> 

I am personally fine with this since I too never assign to built-in 
names, but I can see people raising a stink over this citing that their 
freedoms are being encroached upon.  =)

> The compiler could also warn about references to non-existent names.
> That's a common error and would be helpful to developers.
> 

Isn't this getting into PyChecker's territory?

-Brett



From skip@pobox.com  Mon Jun  9 20:55:22 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 9 Jun 2003 14:55:22 -0500
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
References: <001f01c32e41$b4b7c440$4827a044@oemcomputer>
 <bc23ln$v66$1@main.gmane.org>
 <20030609111854.A1209@tibia.amotlpaa.bogus>
 <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
Message-ID: <16100.58922.539750.551201@montanaro.dyndns.org>

    Raymond> Grep could find most potential changes but I don't see how you
    Raymond> can statically determine whether 'raise x' is a class or
    Raymond> instance without running the code.

I agree no perfect solution is possible, but I think a 90% solution is
easily acheived.  If what's being raised is one of the standard errors and
it's not mentioned as the lhs of an assignment within the module, it's
almost certain that a standard exception class is being raised.  That
reduces the bulk of the problem down to reviewing the automatic changes.

No matter how completely you try to automate the process, any converter or
raise statement locator (like "egrep -n '^[\t ]*raise ' *.py") should print
lines it modifies or discovers in a form which editors like Emacs can parse,
e.g.:

    httplib.py:247:                raise BadStatusLine(line)
    httplib.py:257:                raise BadStatusLine(line)
    httplib.py:259:            raise BadStatusLine(line)
    httplib.py:289:            raise UnknownProtocol(version)
    httplib.py:475:                raise IncompleteRead(s)
    httplib.py:482:            raise ResponseNotReady()
    httplib.py:515:                    raise InvalidURL("nonnumeric port: '%s'" % host[i+1:])
    httplib.py:545:            raise socket.error, msg
    httplib.py:563:                raise NotConnected()
    httplib.py:630:            raise CannotSendRequest()
    httplib.py:697:            raise CannotSendHeader()
    httplib.py:708:            raise CannotSendHeader()
    httplib.py:767:            raise ResponseNotReady()
    httplib.py:915:            raise error(9, 'Bad file descriptor')
    httplib.py:928:            raise UnimplementedFileMode()

This makes it a lot easier to work your way through the lines which need
attention.

(Before people accuse me of being an Emacs bigot I readily admit that I am.
Let me suggest that this magic tool take an optional format parameter which
defaults to something like "%(file)s:%(line)d:%(source)s".  That should
allow the tool to format its output to most any text editor or ide's notions
of what compiler error messages look like.)

Skip


From skip@pobox.com  Mon Jun  9 21:02:21 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 9 Jun 2003 15:02:21 -0500
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <20030609191821.GA22026@glacier.arctrix.com>
References: <20030609191821.GA22026@glacier.arctrix.com>
Message-ID: <16100.59341.319911.484876@montanaro.dyndns.org>

    Neil> It's possible to modify the module dict directly and bypass the
    Neil> warning.  I'm not sure what to do about that. :-(

Make the module dict read-only and some as-yet-to-be-determined time during
import?  That is, upon initial import of a module the dict collecting names
would be made writable, but once it's associated with a module object (or
the import is completed), the dict would be flagged read-only or be
transmogrified into a read-only dict subclass of dict().

Skip


From drifty@alum.berkeley.edu  Mon Jun  9 21:02:57 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Mon, 09 Jun 2003 13:02:57 -0700
Subject: [Python-Dev] python-dev Summary for 2003-05-16 through 2003-05-31
In-Reply-To: <16100.44148.845519.289401@montanaro.dyndns.org>
References: <3EE2749C.4050205@ocf.berkeley.edu>        <20030609143646.GA3272@rmunnlfs> <16100.44148.845519.289401@montanaro.dyndns.org>
Message-ID: <3EE4E7F1.6090607@ocf.berkeley.edu>

Skip Montanaro wrote:
>     >> .. _Python 2.2.3: http://www.python.org./2.2.3/
> 
>     Robin> You've got a typo in that URL: an extra trailing dot after the
>     Robin> ".org".
> 
> Typo perhaps, but it is still a valid name (a trailing dot makes the name
> absolute, much the same way that a leading / makes a Unix path name
> absolute).  If your web browser or email client doesn't grok that (Apple's
> Safari handled it just fine), I'd report it as a bug. ;-)
> 

No typo, but Skip hit it right on the head in his explanation; the dot 
makes the address absolute and thus skips your search domains trying to 
find a match.  Think of the trailing dot as specifying to go to the 
Net's root servers immediately instead of trying to figure out what you 
mean.  The drawback of having me do the summaries; just finished reading 
'UNIX Network Programming' so I am still in the "let's try to justify 
reading over 760 pages in a little over a week" mode.  =)

And yes, if your browser can't handle that address it's broken.  =)

-Brett



From guido@python.org  Mon Jun  9 21:13:22 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 09 Jun 2003 16:13:22 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Mon, 09 Jun 2003 15:02:21 CDT."
 <16100.59341.319911.484876@montanaro.dyndns.org>
References: <20030609191821.GA22026@glacier.arctrix.com>
 <16100.59341.319911.484876@montanaro.dyndns.org>
Message-ID: <200306092013.h59KDM510290@odiug.zope.com>

> Make the module dict read-only and some as-yet-to-be-determined time
> during import?  That is, upon initial import of a module the dict
> collecting names would be made writable, but once it's associated
> with a module object (or the import is completed), the dict would be
> flagged read-only or be transmogrified into a read-only dict
> subclass of dict().

But the dict is still accessible in writable form through globals()
and as the func_globals attribute of any function defined in the
module.  This can't be helped unless we want to totally freeze a
module's contents after it's been imported.

Another hole in the plan is exec statements, or execfile() calls.

I still would like to be able to say "if you add a module global that
corresponds to a built-in name used in the module, the module may
continue to use the built-in name".  As long as we can detect *most*
of the ways of inserting such module globals, the remaining ways could
be declared illegal without making them impossible.

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


From nas@python.ca  Mon Jun  9 21:18:48 2003
From: nas@python.ca (Neil Schemenauer)
Date: Mon, 9 Jun 2003 13:18:48 -0700
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <16100.59341.319911.484876@montanaro.dyndns.org>
References: <20030609191821.GA22026@glacier.arctrix.com> <16100.59341.319911.484876@montanaro.dyndns.org>
Message-ID: <20030609201848.GA22342@glacier.arctrix.com>

Skip Montanaro wrote:
> Make the module dict read-only and some as-yet-to-be-determined time during
> import?

I don't think read-only will fly.  Perhaps we could use a subclass of
dict for the module dict.  It could have an optimized interface for use
by the runtime internals.  The standard dict interface would be slower
and could check for monkey business.

  Neil


From drifty@alum.berkeley.edu  Mon Jun  9 21:17:27 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Mon, 09 Jun 2003 13:17:27 -0700
Subject: [Python-Dev] Exception masking/chaining (was: PEP-317)
In-Reply-To: <3EE4E2F6.2050403@ocf.berkeley.edu>
References: <200306090621.h596LgF24277@oma.cosc.canterbury.ac.nz> <3EE4E2F6.2050403@ocf.berkeley.edu>
Message-ID: <3EE4EB57.2090803@ocf.berkeley.edu>

Brett C. wrote:
> Greg Ewing wrote:
> 
>>> can we now consider implementing chained exceptions as has been 
>>> mentioned here numerous times?
>>
>>
>>
>> I must have missed that. What are chained exceptions?
>>
<SNIP>
> This was discussed on the list between Ping and I think Walter (could be 
> wrong about Walter but I know Ping was involved).  Should be in the 
> Summary archive somewhere; just need to find it.  =)
> 

Found it.

Raymond apparently instigated the thread: 
http://mail.python.org/pipermail/python-dev/2003-January/032492.html

And it continued into the next month: 
http://mail.python.org/pipermail/python-dev/2003-February/032864.html

And you even contributed to the discussion, Greg =) :
http://mail.python.org/pipermail/python-dev/2003-January/032513.html

But the original terminology was "exception masking" so that may have 
been why this didn't ring any bells.

For the impatient you can read the last 3 emails I think (especially the 
absolute last which was authored by Raymond) to get a summary of the 
ideas proposed.

-Brett



From pje@telecommunity.com  Mon Jun  9 21:18:57 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Mon, 09 Jun 2003 16:18:57 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <16100.59341.319911.484876@montanaro.dyndns.org>
References: <20030609191821.GA22026@glacier.arctrix.com>
 <20030609191821.GA22026@glacier.arctrix.com>
Message-ID: <5.1.1.6.0.20030609161553.03e2dab0@telecommunity.com>

At 03:02 PM 6/9/03 -0500, Skip Montanaro wrote:
>     Neil> It's possible to modify the module dict directly and bypass the
>     Neil> warning.  I'm not sure what to do about that. :-(
>
>Make the module dict read-only and some as-yet-to-be-determined time during
>import?  That is, upon initial import of a module the dict collecting names
>would be made writable, but once it's associated with a module object (or
>the import is completed), the dict would be flagged read-only or be
>transmogrified into a read-only dict subclass of dict().

You're forgetting about globals; functions have a func_globals reference to 
their globals dictionary, and if the function modifies any globals, it has 
to be writable.

In any case, I'm not sure what the use case is here for stopping all 
modifications of a module __dict__.  Presumably, if somebody writes to 
__dict__ in order to bypass the warning, they either know what they're 
doing or deserve what they get.  :)



From tim.one@comcast.net  Mon Jun  9 21:29:10 2003
From: tim.one@comcast.net (Tim Peters)
Date: Mon, 09 Jun 2003 16:29:10 -0400
Subject: [Python-Dev] RE: The Python interpreter is not fully thread-safe.
In-Reply-To: <1055160726.3ee4799638627@mcherm.com>
Message-ID: <BIEJKCLHCIOIHAGOKOLHIEBJFOAA.tim.one@comcast.net>

[Michael Chermside]
> Please note that what was confusing the the original poster was
> almost certainly the docs saying that "Python" was not thread-safe
> when what was really intended was, as Tim points out, that Python's
> C api was not thread safe. Using the term "free threading" is fine,
> but also make it clear that it's the _C api_ we're talking about,
> because Python itself (ie, programs coded in pure Python) _IS_
> threadsafe.

Not really, under most meanings of "thread safe".  For example,

"""
id = 0
def getid():
    global id
    id += 1
    return id
"""

wouldn't be considered a thread-safe way to get an id by most people, but

"""
getid = iter(xrange(1, sys.maxint)).next
"""

would be.  Thread safety is a complicated topic, in large part because
whether a chunk of code *is* "thread safe" can't be determined by staring at
it in isolation -- it can only be judged with respect to the specific
invariants a specific app relies on.  The first version of getid() may in
fact be fine for a threaded app with unusually weak requirements.

That's why I'd rather explain the situation than try to reduce it to
buzzword compliance -- the buzzwords here don't have objective,
app-independent, universally accepted meanings.



From fdrake@acm.org  Mon Jun  9 21:45:12 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon, 9 Jun 2003 16:45:12 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <20030609133036.J1359@tibia.amotlpaa.bogus>
References: <003201c32eaf$3b02ce60$8fb5958d@oemcomputer>
 <001f01c32e41$b4b7c440$4827a044@oemcomputer>
 <bc23ln$v66$1@main.gmane.org>
 <20030609111854.A1209@tibia.amotlpaa.bogus>
 <5.1.1.6.0.20030609145000.00a53380@telecommunity.com>
 <200306091903.h59J38Y09921@odiug.zope.com>
 <20030609133036.J1359@tibia.amotlpaa.bogus>
Message-ID: <16100.61912.537609.717119@grendel.zope.com>

Steven Taschuk writes:
 > This came up in python-list not long ago [1], and I raised (heh)
 > exactly that argument.  Alex Martelli counterargued that
 > exceptions are one area in which we *do* usually care about
 > isinstance relationships, since that's how we specify which
 > exceptions to catch.

This is a good point.  So I'll find it annoying, but it does make
sense, so I'll get over it (eventually).


  -Fred

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


From martin@v.loewis.de  Mon Jun  9 21:48:32 2003
From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Jun 2003 22:48:32 +0200
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <200306092013.h59KDM510290@odiug.zope.com>
References: <20030609191821.GA22026@glacier.arctrix.com>              <16100.59341.319911.484876@montanaro.dyndns.org> <200306092013.h59KDM510290@odiug.zope.com>
Message-ID: <3EE4F2A0.6010508@v.loewis.de>

Guido van Rossum wrote:

> I still would like to be able to say "if you add a module global that
> corresponds to a built-in name used in the module, the module may
> continue to use the built-in name".  As long as we can detect *most*
> of the ways of inserting such module globals, the remaining ways could
> be declared illegal without making them impossible.

I'd phrase this differently: Those cases just get a different semantics
then they have now; the module-level name is ignored unless explicitly
qualified. In the spirit of C, hiding builtins would cause "undefined 
behaviour" or "implementation-defined behaviour", and not be "illegal".

Regards,
Martin




From guido@python.org  Mon Jun  9 21:53:49 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 09 Jun 2003 16:53:49 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Mon, 09 Jun 2003 22:48:32 +0200."
 <3EE4F2A0.6010508@v.loewis.de>
References: <20030609191821.GA22026@glacier.arctrix.com> <16100.59341.319911.484876@montanaro.dyndns.org> <200306092013.h59KDM510290@odiug.zope.com>
 <3EE4F2A0.6010508@v.loewis.de>
Message-ID: <200306092053.h59Krna10630@odiug.zope.com>

> Guido van Rossum wrote:
> 
> > I still would like to be able to say "if you add a module global that
> > corresponds to a built-in name used in the module, the module may
> > continue to use the built-in name".  As long as we can detect *most*
> > of the ways of inserting such module globals, the remaining ways could
> > be declared illegal without making them impossible.
> 
> I'd phrase this differently: Those cases just get a different semantics
> then they have now; the module-level name is ignored unless explicitly
> qualified. In the spirit of C, hiding builtins would cause "undefined 
> behaviour" or "implementation-defined behaviour", and not be "illegal".

I don't think the spirit of C applies here.  I want to be able to tell
anyone who does one of these things that their program is illegal (or
invalid, or some other pejorative term), not just undefined, and
certainly not implementation-defined.  Otherwise a future
implementation couldn't detect such illegal programs and reject them
at compile time or at least raise an exception at run-time.

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


From barry@python.org  Mon Jun  9 21:55:34 2003
From: barry@python.org (Barry Warsaw)
Date: 09 Jun 2003 16:55:34 -0400
Subject: [Python-Dev] mimetypes.guess_all_extensions()
Message-ID: <1055192134.29829.59.camel@barry>

I think mimetypes.guess_all_extensions() is broken in its return value
when there are no matching extensions.  Currently it returns None when
there are no matching extensions[*], but I think it would be better to
simply return an empty list.  I have an application where I want to
iterate over the return values, but I have to add a (IMO) useless hack:

for ext in guess_all_extensions(mytype, strict=False) or []:
   # blah

Seems like this would be a common use case.  So what does returning None
instead of an empty list buy you anyway?  Since both are false, it
should be fine to just remove the last two lines of the method.

This method is new in Python 2.3 so I don't think backwards
compatibility should be an issue.  It's a simple fix; are there any
objections?

-Barry

[*] The way the method returns None in the no-match case is bogus
anyway.  IMO, it shouldn't return None implicitly simply by virtue of
falling off the end of the def.




From nas@python.ca  Mon Jun  9 22:09:54 2003
From: nas@python.ca (Neil Schemenauer)
Date: Mon, 9 Jun 2003 14:09:54 -0700
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <5.1.1.6.0.20030609161553.03e2dab0@telecommunity.com>
References: <20030609191821.GA22026@glacier.arctrix.com> <20030609191821.GA22026@glacier.arctrix.com> <5.1.1.6.0.20030609161553.03e2dab0@telecommunity.com>
Message-ID: <20030609210953.GA22752@glacier.arctrix.com>

Phillip J. Eby wrote:
> Presumably, if somebody writes to __dict__ in order to bypass the
> warning, they either know what they're doing or deserve what they get.

I'm not sure about that.  Think about using globals().  Eg.

    exec somecode in globals()

or:

    d = globals()
    d['range'] = 'ha ha'

I especially worried about code that provides an interactive interface
(e.g IDLE and pyrepl).

  Neil


From skip@pobox.com  Mon Jun  9 22:09:08 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 9 Jun 2003 16:09:08 -0500
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <200306092013.h59KDM510290@odiug.zope.com>
References: <20030609191821.GA22026@glacier.arctrix.com>
 <16100.59341.319911.484876@montanaro.dyndns.org>
 <200306092013.h59KDM510290@odiug.zope.com>
Message-ID: <16100.63348.389728.90228@montanaro.dyndns.org>

    >> Make the module dict read-only ...

    Guido> But the dict is still accessible in writable form through
    Guido> globals() and as the func_globals attribute of any function
    Guido> defined in the module.

I was thinking more along the lines of making the dict itself read-only.

Skip


From fdrake@acm.org  Mon Jun  9 22:12:47 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon, 9 Jun 2003 17:12:47 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <16100.63348.389728.90228@montanaro.dyndns.org>
References: <20030609191821.GA22026@glacier.arctrix.com>
 <16100.59341.319911.484876@montanaro.dyndns.org>
 <200306092013.h59KDM510290@odiug.zope.com>
 <16100.63348.389728.90228@montanaro.dyndns.org>
Message-ID: <16100.63567.723086.683341@grendel.zope.com>

Skip Montanaro writes:
 > I was thinking more along the lines of making the dict itself read-only.

That certainly makes global variables more difficult, doesn't it?  The
interpreter could worm around it, but it's not clear that this is the
right solution.


  -Fred

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


From tim.one@comcast.net  Mon Jun  9 22:12:29 2003
From: tim.one@comcast.net (Tim Peters)
Date: Mon, 09 Jun 2003 17:12:29 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <200306092053.h59Krna10630@odiug.zope.com>
Message-ID: <BIEJKCLHCIOIHAGOKOLHGECAFOAA.tim.one@comcast.net>

[Guido]
> I don't think the spirit of C applies here.  I want to be able to tell
> anyone who does one of these things that their program is illegal (or
> invalid, or some other pejorative term), not just undefined, and
> certainly not implementation-defined.  Otherwise a future
> implementation couldn't detect such illegal programs and reject them
> at compile time or at least raise an exception at run-time.

As the C standard uses the word "undefined", compile-time rejection of a
program with undefined semantics is fine.  Nothing is defined about what
happens in the face of undefined behavior, so nobody can object to anything
that happens!

    undefined behavior

    behavior, upon use of a nonportable or erroneous program construct
    or of erroneous data, for which this International Standard imposes
    no requirements

    NOTE Possible undefined behavior ranges from ignoring the situation
    completely with unpredictable results, to behaving during translation
    or program execution in a documented manner characteristic of the
    environment (with or without the issuance of a diagnostic message),
    to terminating a translation or execution (with the issuance of a
    diagnostic message).

    EXAMPLE An example of undefined behavior is the behavior on
    integer overflow.



From skip@pobox.com  Mon Jun  9 22:30:29 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 9 Jun 2003 16:30:29 -0500
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <16100.63567.723086.683341@grendel.zope.com>
References: <20030609191821.GA22026@glacier.arctrix.com>
 <16100.59341.319911.484876@montanaro.dyndns.org>
 <200306092013.h59KDM510290@odiug.zope.com>
 <16100.63348.389728.90228@montanaro.dyndns.org>
 <16100.63567.723086.683341@grendel.zope.com>
Message-ID: <16100.64629.237742.148613@montanaro.dyndns.org>

    Skip> I was thinking more along the lines of making the dict itself
    Skip> read-only.

    Fred> That certainly makes global variables more difficult, doesn't it?

Yes, but we all know globals are bad, right? ;-)

At first blush, it doesn't seem all that tough to worm around this in the
interpreter (postulating a read_only flag for dicts or at least for that
variety of dict used as a module dict):

    case STORE_GLOBAL:
            w = GETITEM(names, oparg);
            v = POP();
            ro = f->f_globals->read_only;
            f->f_globals->read_only = 0;
            err = PyDict_SetItem(f->f_globals, w, v);
            f->f_globals->read_only = ro;
            Py_DECREF(v);
            break;

or something like that.  I think the STORE_GLOBAL instruction will only be
executed to set a global in the current module.  Any foreign setting,
e.g. "fileinput.open = 10", will be handled by STORE_ATTR.  Can executing
PyDict_SetItem() cause arbitrary Python code to execute?

(I'm almost purposely adopting an XP approach here - do just enough to
address the current breakage and see what the next problem is which pops
up.)

Skip


From barry@python.org  Mon Jun  9 22:48:41 2003
From: barry@python.org (Barry Warsaw)
Date: 09 Jun 2003 17:48:41 -0400
Subject: [Python-Dev] mimetypes.guess_all_extensions()
In-Reply-To: <1055192134.29829.59.camel@barry>
References: <1055192134.29829.59.camel@barry>
Message-ID: <1055195321.29829.71.camel@barry>

On Mon, 2003-06-09 at 16:55, Barry Warsaw wrote:

> I think it would be better to
> simply return an empty list.

> This method is new in Python 2.3 so I don't think backwards
> compatibility should be an issue.  It's a simple fix; are there any
> objections?

The BDFL agrees.  Since there were no unittests of
guess_all_extensions() I added some while updating the docs and
docstrings.  I'll check it all in once I've confirmed there are no other
test failures.

-Barry




From drifty@alum.berkeley.edu  Mon Jun  9 22:55:55 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Mon, 09 Jun 2003 14:55:55 -0700
Subject: [Python-Dev] [OT] Thank you, python-dev
Message-ID: <3EE5026B.1040708@ocf.berkeley.edu>

I just decided that I am going to attend Cal Poly SLO this Fall for grad 
school in CS.  The possibility of attending any grad school would not 
have been possible if it was not for everyone on this list that I have 
had the pleasure of interacting with (my Python work made up the bulk of 
my application).

When I joined the list I was just some kid who loved programming (still 
am, actually =) but had zero confidence in his abilities.  Then, as I 
listened on the list, observing how real development was done, I began 
to learn.

When I picked up the Summaries I had an inkling of how Python's 
internals worked.  Now I know how a huge C code base can magically make 
a bunch of text written in some whitespace-heavy language into something 
cool.

And when I got CVS access I was scared out of my wits of touching other 
people's code and applied patches.  Now I have managed to do that, fix 
my own broken code, and cause several tests to fail and break other 
people's code.  As you can tell I am still working on this one.  =)

I know there is no way I would be anywhere near the level of coder that 
I am now if it was not for everyone on this list.  You all have given me 
almost every major personal programming achievement in my life.  I feel 
like I can call myself a programmer now thanks to all of you.

So, thanks to all.  This means I ain't goin' no where now so you guys 
are going to have to keep putting up with me.  =)

-Brett



From creedy@mitretek.org  Mon Jun  9 23:15:30 2003
From: creedy@mitretek.org (Chris Reedy)
Date: Mon, 09 Jun 2003 18:15:30 -0400
Subject: [Python-Dev] towards a faster Python
Message-ID: <3EE50702.1080107@mitretek.org>

Neil Schemenauer wrote:

> The goal is that the compiler should be able to determine the scope of a
> name at compile time.  Code like the above does not allow that and so
> non-local names must be searched for in both globals and builtins at run
> time.  Unfortunately the warning is not bulletproof.  It's possible to
> modify the module dict directly and bypass the warning.  I'm not sure
> what to do about that. :-(

I think you might be looking for a test something like:

class special_dict(dict):
      """Special dictionary that doesn't allow changes to built-in names."""

      def __setitem__(self, key, value):
          if(key in self and hasattr(self[key], '__builtin_name__')
                         and key == self[key].__builtin_name__):
              raise_or_warn_changing_builtin(self, key, value)
          super(special_dict, self).__setitem__(key,value)

where __builtin_name__ is a new special attribute that would appear only
on built-in objects that aren't supposed to have their names changed.
The class special_dict would be used in situations where these kinds of
changes aren't supposed to occur. (Of course, I'd expect this to be
implemented in C in the guts of the interpreter for the obvious
performance reasons.)

This approach allows code like, for example:

     globals().myownrange = range
     ...
     for i in myownrange(5):
       ...

     Chris

P.S. I've been a lurker on this list for some time. I now propose to
climb back under my rock.

This is informal and not an official Mitretek Systems position.
Dr. Christopher L. Reedy, Senior Principal Software Engineer
Mitretek Systems
Email: creedy@mitretek.org







From greg@cosc.canterbury.ac.nz  Mon Jun  9 23:35:15 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Jun 2003 10:35:15 +1200 (NZST)
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <20030609145131.GA20606@epoch.metaslash.com>
Message-ID: <200306092235.h59MZFQ05461@oma.cosc.canterbury.ac.nz>

I'm worried about the proposed elimination of deferred instantiation
of exceptions in Python code. The PEP asserts that this is an
optimisation that should only be of interest in C code.

But in Pyrex, the distinction between Python and C is
blurred. Currently, if you raise an exception in Pyrex using the
implicit instantiation syntax, instantiation is also deferred, and I
think this is a good thing.  But if the implicit instantiation syntax
goes away, this will no longer be possible while keeping the same
syntax for the raise statement in Python and Pyrex.

It seems to me it's not necessary to eliminate implicit instantiation
altogether, but only to remove the ambiguity between implicit and
explicit instantiation. This could be done by mandating that

   raise expr

*never* instantiates implicitly, whereas

   raise classexpr, valueexpr

*always* instantiates implicitly, possibly also deferred.

Specification of a traceback would be done with a new keyword, e.g.

   raise expr [,expr] traceback tb

which I think is a good idea anyway, since it makes it a lot clearer
what the currently-somewhat-obscure third argument actually is.

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


From greg@cosc.canterbury.ac.nz  Mon Jun  9 23:38:56 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Jun 2003 10:38:56 +1200 (NZST)
Subject: [Python-Dev] PEP-317
In-Reply-To: <3EE4A1B5.2090101@llnl.gov>
Message-ID: <200306092238.h59Mcuo05465@oma.cosc.canterbury.ac.nz>

Pat Miller <patmiller@llnl.gov>:

> I still "casually" use string exceptions mostly as a shortcut to get
> unfinished code to bomb (or to generate a quick traceback.
>
>   raise 'zz'

You could use

  assert 0, 'zz'

instead.

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


From rmunn@pobox.com  Mon Jun  9 23:47:26 2003
From: rmunn@pobox.com (Robin Munn)
Date: Mon, 9 Jun 2003 17:47:26 -0500
Subject: [Python-Dev] python-dev Summary for 2003-05-16 through 2003-05-31
In-Reply-To: <3EE4E7F1.6090607@ocf.berkeley.edu>
References: <3EE2749C.4050205@ocf.berkeley.edu> <20030609143646.GA3272@rmunnlfs> <16100.44148.845519.289401@montanaro.dyndns.org> <3EE4E7F1.6090607@ocf.berkeley.edu>
Message-ID: <20030609224726.GB4625@rmunnlfs>

--i9LlY+UWpKt15+FH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 09, 2003 at 01:02:57PM -0700, Brett C. wrote:
> Skip Montanaro wrote:
> >    >> .. _Python 2.2.3: http://www.python.org./2.2.3/
> >
> >    Robin> You've got a typo in that URL: an extra trailing dot after the
> >    Robin> ".org".
> >
> >Typo perhaps, but it is still a valid name (a trailing dot makes the name
> >absolute, much the same way that a leading / makes a Unix path name
> >absolute).  If your web browser or email client doesn't grok that (Apple=
's
> >Safari handled it just fine), I'd report it as a bug. ;-)
> >
>=20
> No typo, but Skip hit it right on the head in his explanation; the dot=20
> makes the address absolute and thus skips your search domains trying to=
=20
> find a match.  Think of the trailing dot as specifying to go to the=20
> Net's root servers immediately instead of trying to figure out what you=
=20
> mean.  The drawback of having me do the summaries; just finished reading=
=20
> 'UNIX Network Programming' so I am still in the "let's try to justify=20
> reading over 760 pages in a little over a week" mode.  =3D)
>=20
> And yes, if your browser can't handle that address it's broken.  =3D)

Ah, I see. My browser handled it just fine, but I assumed it was a typo
because I didn't know that was valid usage and, well, the . key is right
next to the / key... :-)

I'd still consider changing it to the more-commonly-used form without a
trailing dot, though, simply to avoid confusing people on c.l.py. Or you
could leave it in, figuring that anyone who reads the python-dev
summaries is smart enough to understand what's going on. Your call.

--=20
Robin Munn <rmunn@pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838    50FF 2478 CFFB 081A 8338  54F7 845D ACFD 6AFB 6838

--i9LlY+UWpKt15+FH
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+5Q5+hF2s/Wr7aDgRAsckAJ9J6Ww1tUmaBgLTpKycg9V11ufDSQCgkmjN
unvnPBfXPM7Un3u/tDs8y8E=
=3rbC
-----END PGP SIGNATURE-----

--i9LlY+UWpKt15+FH--


From greg@cosc.canterbury.ac.nz  Mon Jun  9 23:48:03 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Jun 2003 10:48:03 +1200 (NZST)
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306091903.h59J38Y09921@odiug.zope.com>
Message-ID: <200306092248.h59Mm3Y05484@oma.cosc.canterbury.ac.nz>

> I don't have a use case that breaks with this requirement (since you
> can always use multiple inheritance to make a desirable class
> raisable).

What if the desirable class has a C layout that conflicts
with that of Exception?

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


From greg@cosc.canterbury.ac.nz  Mon Jun  9 23:51:16 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Jun 2003 10:51:16 +1200 (NZST)
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <20030609191821.GA22026@glacier.arctrix.com>
Message-ID: <200306092251.h59MpGY05494@oma.cosc.canterbury.ac.nz>

Neil Schemenauer <nas@python.ca>:

> Unfortunately the warning is not bulletproof.  It's possible to
> modify the module dict directly and bypass the warning.  I'm not
> sure what to do about that. :-(

I'd say don't bother doing anything. Anyone who messes
around with things at that low a level deserves whatever
they get. :-)

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


From paul@pfdubois.com  Mon Jun  9 23:53:07 2003
From: paul@pfdubois.com (Paul F Dubois)
Date: Mon, 9 Jun 2003 15:53:07 -0700
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <20030609210701.28795.84218.Mailman@mail.python.org>
Message-ID: <000301c32ed9$e531c150$6501a8c0@NICKLEBY>

Some builtins have names that are "obvious", such as "open". That makes them
"obvious" names to want to use in other contexts. For example, I have a
module mykindoffile and I want to be able to say mykindoffile.open('xxxx').

Imagine that mykindoffile is in Python; then mykindoffile.py might want to
define open using an underlying extension:

import _mykindoffile
open = _mykindoffile.open

Now imagine that mykindoffile is a package. I might have in
mykindoffile/__init__.py something like:

from myopener import open

Now in all these cases I am setting an attribute in a module, but in a way
that Python could detect when compiling mykindoffile. This is the kind of
thing I do all the time.

But there are, as noted, cases where Python cannot reasonably see what you
are doing such as:
mykindoffile.open = myopenf
exec 'open=_mykindoffile.open' in mykindoffile 

I feel that being able to use names like open is important, but it would be
a rats nest to say that there were some ways you could do it and succeed,
some that gave warning errors and might or might not fail, and some that
could mysteriously fail without warning.

Making a module dictionary readonly after importation would break legendary
amounts of code. In fact, what I wish all the time is that a module was a
kind of singleton class instance so that I could use properties,
descriptors, etc. in it. 





From pje@telecommunity.com  Mon Jun  9 23:55:14 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Mon, 09 Jun 2003 18:55:14 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306092248.h59Mm3Y05484@oma.cosc.canterbury.ac.nz>
References: <200306091903.h59J38Y09921@odiug.zope.com>
Message-ID: <5.1.1.6.0.20030609185440.022210a0@telecommunity.com>

At 10:48 AM 6/10/03 +1200, Greg Ewing wrote:
> > I don't have a use case that breaks with this requirement (since you
> > can always use multiple inheritance to make a desirable class
> > raisable).
>
>What if the desirable class has a C layout that conflicts
>with that of Exception?

Can't Exception be "abstract" with respect to layout?



From greg@cosc.canterbury.ac.nz  Tue Jun 10 00:12:13 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Jun 2003 11:12:13 +1200 (NZST)
Subject: [Python-Dev] PEP-317
In-Reply-To: <3EE4E2F6.2050403@ocf.berkeley.edu>
Message-ID: <200306092312.h59NCDK05605@oma.cosc.canterbury.ac.nz>

> It was brought up once that raising an exception after another
> exception was already raised ... causes the original exception to be
> ignored.  It was suggested to keep a reference to the previous
> exception in the current exception

Ah, I see, thanks.

Also while we're at it, how about storing the traceback in the
exception object, and getting rid of sys.exc_info() etc.?

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


From staschuk@telusplanet.net  Tue Jun 10 00:45:58 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Mon, 9 Jun 2003 17:45:58 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306092235.h59MZFQ05461@oma.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Tue, Jun 10, 2003 at 10:35:15AM +1200
References: <20030609145131.GA20606@epoch.metaslash.com> <200306092235.h59MZFQ05461@oma.cosc.canterbury.ac.nz>
Message-ID: <20030609174558.B2982@tibia.amotlpaa.bogus>

Quoth Greg Ewing:
> I'm worried about the proposed elimination of deferred instantiation
> of exceptions in Python code. The PEP asserts that this is an
> optimisation that should only be of interest in C code.

Yes -- and without argument!  I quite liked writing that bit.

Btw, just to be clear: in pure Python, deferred instantiation is
already impossible; implicit instantiation is exactly equivalent
to explicit.

I admit I hadn't thought of Pyrex at all.  I see that the
trade-offs are different there, and deferring instantiation might
well make lots of sense.

  [...]
> It seems to me it's not necessary to eliminate implicit instantiation
> altogether, but only to remove the ambiguity between implicit and
> explicit instantiation. This could be done by mandating that
> 
>    raise expr
> 
> *never* instantiates implicitly, whereas
> 
>    raise classexpr, valueexpr
> 
> *always* instantiates implicitly, possibly also deferred.

In this plan, in order to raise, say, a TypeError with deferred
instantiation and no arguments, you'd have to write

    raise TypeError, ()

right?

> Specification of a traceback would be done with a new keyword, e.g.
> 
>    raise expr [,expr] traceback tb
> 
> which I think is a good idea anyway, since it makes it a lot clearer
> what the currently-somewhat-obscure third argument actually is.

I like that.

I would also like the traceback to be an attribute of the
exception object (circular references be damned!), specified by
optional keyword argument to Exception.__init__.  This would
require that people writing their own exception classes be sure to
extend, not override, Exception.__init__.

-- 
Steven Taschuk                               staschuk@telusplanet.net
"[T]rue greatness is when your name is like ampere, watt, and fourier
 -- when it's spelled with a lower case letter."      -- R.W. Hamming


From mrussell@verio.net  Tue Jun 10 01:06:59 2003
From: mrussell@verio.net (Mark Russell)
Date: Tue, 10 Jun 2003 01:06:59 +0100
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Mon, 09 Jun 2003 19:39:01 EDT."
 <20030609233901.2675.1181.Mailman@mail.python.org>
Message-ID: <E19PWfE-0004vy-00@straylight>

Paul F Dubois <paul@pfdubois.com>:

>Making a module dictionary readonly after importation would break legendary
>amounts of code.

Perhaps a way round this would be to flag modules in some way.  For example,
an export statement with the following semantics:

    - Has the form "export name1, name2, name3"

    - Exported names must be bound in the module body (at some point
      after the export statement)

    - Export statements must appear before any others (apart from doc
      strings and comments)

    - The presence of the export statement makes binding or unbinding names
      in the module's dict illegal after the module has been loaded

    - Only exported names can be imported into other modules (in the same
      way as before - i.e. export would NOT imply automatic insertion into
      other namespaces)

    - No export statements means use the current rules (everything
      exported, module dict stays writable)

I think this would be an intuitively obvious addition, and these rules
would mean that the compiler would be free to make assumptions about the
meaning of builtins etc in a module.

Mark
      
       



	




From greg@cosc.canterbury.ac.nz  Tue Jun 10 01:17:01 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Jun 2003 12:17:01 +1200 (NZST)
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <20030609174558.B2982@tibia.amotlpaa.bogus>
Message-ID: <200306100017.h5A0H1E05944@oma.cosc.canterbury.ac.nz>

Steven Taschuk <staschuk@telusplanet.net>:

> Btw, just to be clear: in pure Python, deferred instantiation is
> already impossible; implicit instantiation is exactly equivalent
> to explicit.

I know that's the way it *is*, but I can't see any reason why the
interpreter couldn't defer instantiation if it wanted to. It should be
an optimisation that any part of the implementation is free to make if
the programmer hasn't explicitly instantiated before raising.

> In this plan, in order to raise, say, a TypeError with deferred
> instantiation and no arguments, you'd have to write
>
>    raise TypeError, ()

Hmmm, yes, it would appear so. I must admit that does look
a bit ugly.

But something else has occurred to me. If we're going to require
exception classes to be derived from Exception, then there's no
ambiguity anyway, because you can't have an object which is both a
subclass of Exception and an instance of a subclass of Exception. (At
least not without pulling some sort of bizarre trick, and I don't
much care what happens to anyone who does that.-)

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


From guido@python.org  Tue Jun 10 01:23:39 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 09 Jun 2003 20:23:39 -0400
Subject: [Python-Dev] PEP-317
In-Reply-To: "Your message of Tue, 10 Jun 2003 11:12:13 +1200."
 <200306092312.h59NCDK05605@oma.cosc.canterbury.ac.nz>
References: <200306092312.h59NCDK05605@oma.cosc.canterbury.ac.nz>
Message-ID: <200306100023.h5A0NdX15842@pcp02138704pcs.reston01.va.comcast.net>

> Also while we're at it, how about storing the traceback in the
> exception object, and getting rid of sys.exc_info() etc.?

That's a good idea, and I'd support a PEP on that topic more than PEP
317 (which IMO is unnecessary).

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


From guido@python.org  Tue Jun 10 01:22:25 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 09 Jun 2003 20:22:25 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: "Your message of Tue, 10 Jun 2003 10:48:03 +1200."
 <200306092248.h59Mm3Y05484@oma.cosc.canterbury.ac.nz>
References: <200306092248.h59Mm3Y05484@oma.cosc.canterbury.ac.nz>
Message-ID: <200306100022.h5A0MPt15825@pcp02138704pcs.reston01.va.comcast.net>

> > I don't have a use case that breaks with this requirement (since you
> > can always use multiple inheritance to make a desirable class
> > raisable).
> 
> What if the desirable class has a C layout that conflicts
> with that of Exception?

Perhaps Exception should have a null C layout?

But I still call YAGNI on this use case until I hear a good reason why
you'd ever want to raise a 3rd party class and it's not (a) for
backwards compatibility reasons or (b) just as easy to raise another
class with this class instance as an attribute.

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


From guido@python.org  Tue Jun 10 01:30:19 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 09 Jun 2003 20:30:19 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: "Your message of Mon, 09 Jun 2003 15:53:07 PDT."
 <000301c32ed9$e531c150$6501a8c0@NICKLEBY>
References: <000301c32ed9$e531c150$6501a8c0@NICKLEBY>
Message-ID: <200306100030.h5A0UJt15875@pcp02138704pcs.reston01.va.comcast.net>

> Some builtins have names that are "obvious", such as "open". That makes them
> "obvious" names to want to use in other contexts. For example, I have a
> module mykindoffile and I want to be able to say mykindoffile.open('xxxx').
> 
> Imagine that mykindoffile is in Python; then mykindoffile.py might want to
> define open using an underlying extension:
> 
> import _mykindoffile
> open = _mykindoffile.open
> 
> Now imagine that mykindoffile is a package. I might have in
> mykindoffile/__init__.py something like:
> 
> from myopener import open
> 
> Now in all these cases I am setting an attribute in a module, but in a way
> that Python could detect when compiling mykindoffile. This is the kind of
> thing I do all the time.

None of these are affected by Neil's change.  Whenever a module
changes its *own* globals to shadow builtins, the parser can see the
change and can adjust its list of builtins that it can optimize.

> But there are, as noted, cases where Python cannot reasonably see what you
> are doing such as:
> mykindoffile.open = myopenf
> exec 'open=_mykindoffile.open' in mykindoffile 

Right.  Neil's patch warns about the first one; the second one is
dubious use (fortunately, to make it work, you'd actually have to
write 

  exec 'open=_mykindoffile.open' in mykindoffile.__dict__

which already signals "hack" to me.

If a module writes

  exec '...' in globals()

the parser can be warned, so this shouldn't be a problem.

> I feel that being able to use names like open is important, but it
> would be a rats nest to say that there were some ways you could do
> it and succeed, some that gave warning errors and might or might not
> fail, and some that could mysteriously fail without warning.

We should try to really minimize the latter kinds.  I think Neil's
patch is an important first step/

> Making a module dictionary readonly after importation would break
> legendary amounts of code.

And this won't ever happen.

> In fact, what I wish all the time is that a module was a kind of
> singleton class instance so that I could use properties,
> descriptors, etc. in it.

This won't ever happen either.  When you want a class, use one. :-)

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


From greg@cosc.canterbury.ac.nz  Tue Jun 10 01:23:34 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Jun 2003 12:23:34 +1200 (NZST)
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306100022.h5A0MPt15825@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <200306100023.h5A0NYn05980@oma.cosc.canterbury.ac.nz>

Guido van Rossum <guido@python.org>:

> But I still call YAGNI on this use case until I hear a good reason why
> you'd ever want to raise a 3rd party class and it's not (a) for
> backwards compatibility reasons or (b) just as easy to raise another
> class with this class instance as an attribute.

I'm happy with that.

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


From greg@cosc.canterbury.ac.nz  Tue Jun 10 01:31:15 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 10 Jun 2003 12:31:15 +1200 (NZST)
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <E19PWfE-0004vy-00@straylight>
Message-ID: <200306100031.h5A0VFk06023@oma.cosc.canterbury.ac.nz>

Mark Russell <mrussell@verio.net>:

>    - The presence of the export statement makes binding or unbinding names
>      in the module's dict illegal after the module has been loaded

This would seem to be arbitrarily tying together two
unrelated features. 

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


From python@rcn.com  Tue Jun 10 02:07:48 2003
From: python@rcn.com (Raymond Hettinger)
Date: Mon, 9 Jun 2003 21:07:48 -0400
Subject: [Python-Dev] Re: PEP-317
References: <20030609145131.GA20606@epoch.metaslash.com> <200306092235.h59MZFQ05461@oma.cosc.canterbury.ac.nz> <20030609174558.B2982@tibia.amotlpaa.bogus>
Message-ID: <000301c32eed$d1df3920$3f28a044@oemcomputer>

> Btw, just to be clear: in pure Python, deferred instantiation is
> already impossible; implicit instantiation is exactly equivalent
> to explicit.

Almost exactly:

>>> def f():
 raise ValueError, 1

>>> def g():
 raise ValueError(1)

>>> from dis import dis
>>> dis(f)
  2           0 LOAD_GLOBAL              0 (ValueError)
              3 LOAD_CONST               1 (1)
              6 RAISE_VARARGS            2
              9 LOAD_CONST               0 (None)
             12 RETURN_VALUE        
>>> dis(g)
  2           0 LOAD_GLOBAL              0 (ValueError)
              3 LOAD_CONST               1 (1)
              6 CALL_FUNCTION            1
              9 RAISE_VARARGS            1
             12 LOAD_CONST               0 (None)
             15 RETURN_VALUE 



On a separate note, I was experimented with explicit instantiation 
and noticed an oddity with my editor's autocomplete.  Upon typing:

    raise TypeError(

the autocompleter looks up the doc string for TypeError and announces:

    Inappropriate argument type

when you were likely expecting to be prompted for the exception value.
Perhaps the doc string should read like this:

   TypeError([exceptionvalue]) --> Exception for inappropriate argument type.



Raymond Hettinger



From tim@zope.com  Tue Jun 10 03:56:17 2003
From: tim@zope.com (Tim Peters)
Date: Mon, 9 Jun 2003 22:56:17 -0400
Subject: [Python-Dev] [OT] Thank you, python-dev
In-Reply-To: <3EE5026B.1040708@ocf.berkeley.edu>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEJJEJAB.tim@zope.com>

[Brett "Grad Boy" Cannon]
> ...
> And when I got CVS access I was scared out of my wits of touching
> other people's code and applied patches.  Now I have managed to do
> that, fix my own broken code, and cause several tests to fail and
> break other people's code.  As you can tell I am still working on
> this one.  =)

This is normal, and a good sign.  I've only worked for two companies that
had any concept of "career development" (beyond just tolerating it when they
couldn't stop it <0.5 wink>), and in those it was always true that a new
college-grad hire was useless until they lost their fear of breaking the
code.  It's like the human body that way:  we learn a lot more about how it
works by studying disease than by admiring a perfect specimen.  It's only
when the guts spill out all over the floor that you can learn what all those
misshapen juicy bits *really* do.

> I know there is no way I would be anywhere near the level of coder
> that I am now if it was not for everyone on this list.  You all have
> given me almost every major personal programming achievement in my
> life.  I feel like I can call myself a programmer now thanks to all
> of you.

Sorry, not a chance:  you're not a real programmer until your arrogance has
put at least one startup out of business <wink>.

working-on-my-fifth-but-i'm-old-ly y'rs  - tim



From zen@shangri-la.dropbear.id.au  Tue Jun 10 06:57:50 2003
From: zen@shangri-la.dropbear.id.au (Stuart Bishop)
Date: Tue, 10 Jun 2003 15:57:50 +1000
Subject: [Python-Dev] python-dev Summary for 2003-05-16 through 2003-05-31
In-Reply-To: <3EE2749C.4050205@ocf.berkeley.edu>
Message-ID: <77FF0500-9B08-11D7-819D-000A95A06FC6@shangri-la.dropbear.id.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sunday, June 8, 2003, at 09:26  AM, Brett C. wrote:

> `test_time fails with current CVS`__
>     No follow-up to this email so I don't know if MA Lemburg's issue 
> with time.tzset was solved.

In the bugtracker, and would have been fixed by now except that it
appears to be flu season here.

- -- 
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE+5XNjh8iUz1x5geARAqXkAJwOeTq1P2+JiQV7bO5MttSVFBYeNACgyhHV
VETUPSBi0YjeygA3+XzQ1No=
=NalR
-----END PGP SIGNATURE-----



From staschuk@telusplanet.net  Tue Jun 10 07:11:18 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Tue, 10 Jun 2003 00:11:18 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306100017.h5A0H1E05944@oma.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Tue, Jun 10, 2003 at 12:17:01PM +1200
References: <20030609174558.B2982@tibia.amotlpaa.bogus> <200306100017.h5A0H1E05944@oma.cosc.canterbury.ac.nz>
Message-ID: <20030610001118.B3788@tibia.amotlpaa.bogus>

Quoth Greg Ewing:
  [...]
> I know that's the way it *is*, but I can't see any reason why the
> interpreter couldn't defer instantiation if it wanted to. It should be
> an optimisation that any part of the implementation is free to make if
> the programmer hasn't explicitly instantiated before raising.

The interpreter certainly could do that, but imho it would be a
Bad Thing.  Forgive my long-windedness, but:

Imho, it's bad enough that
    raise MyError, 'foo'
    raise MyError('foo')
are two ways of saying the same thing; that's merely confusing.
But having the interpreter defer instantiation in the former case
would make them a much worse pair -- two subtly different ways of
saying almost the same thing, where the difference is one you
almost never care about.  I cringe.

To be more concrete, if exception instantiation might be deferred
and might not occur at all, then (off the top of my head):

    1. Logging code in an exception's __init__ might be called,
    might not.

    2. sys._getframe tricks in an exception's __init__ might work,
    might not.  (And exceptions are just the kind of infrastructure-
    level thing where such tricks are most likely to be useful, imho.
    You might, for example, want to grab a copy of all the locals of
    the function which raised the exception, for error reporting.
    Sure you could use the traceback, if you can get ahold of it
    somehow, but everywhere *else* this kind of machinery uses
    sys._getframe, so...)

    3. Implementations of __new__ in which the created object is not
    of the requested class would make the exception type depend on
    whether instantiation was deferred or not, affecting whether and
    when it gets caught.

Perhaps these aren't showstoppers, but I really like it when
optimizations are completely transparent.

Besides, almost all raise statements report errors which prevent
normal processing, and so have no use for such an optimization
anyway.  And even when using exceptions for control flow on
performance- critical paths, you can avoid paying the
instantiation cost in inner loops by other, simpler, means --
e.g., create one instance of your FancyControlFlow exception up
front and raise that one object as needed.

There's also some (surmountable) implementation issues:  Suppose
we enter an except block without instantiating the exception; what
are the values of sys.exc_type etc. then?  Are they possibly
denormalized?  Or do we remove sys.exc_{type, value, traceback}
entirely, and have calling sys.exc_info() cause instantiation?

If explicit instantiation were standard, and the implicit
instantiation syntax were now being proposed with deferred-and-
skipped-if-possible semantics, I might just be -0 YAGNI on it.  In
that scenario, this syntax would be something weird that
programmers would only use if they knew they needed it.  But the
actual circumstance is, to judge by the stdlib, that implicit
instantiation is today the de facto standard way to raise an
exception.  Thus adding such semantics now would give the normal
form weird behaviour to enable an optimization which is useful
only in specialized circumstances -- which puts me firmly in the
-1 AAAGH! camp.

All of the above is intended for pure Python only.  If the
tradeoffs are much different in Pyrex, I'd like to hear more
details.

  [...]
> But something else has occurred to me. If we're going to require
> exception classes to be derived from Exception, then there's no
> ambiguity anyway, [...]

For old-style classes, there's no ambiguity now, either.  But yes,
requiring inheritance from Exception seems to eliminate any
instance/class ambiguities for future new-style exceptions too.
(It also avoids certain other problems; see Alex's persuasive
arguments in c.l.py around the beginning of May, mentioned
elsewhere in this thread.)

PEP 317 isn't primarily concerned with that ambiguity, of course;
more with the loss of clarity in present-day everyday code.

> [...] because you can't have an object which is both a
> subclass of Exception and an instance of a subclass of Exception.  (At
> least not without pulling some sort of bizarre trick, and I don't
> much care what happens to anyone who does that.-)

Couldn't agree more.

-- 
Steven Taschuk                          staschuk@telusplanet.net
"Its force is immeasurable.  Even Computer cannot determine it."
                           -- _Space: 1999_ episode "Black Sun"


From yweng@cs.uoregon.edu  Tue Jun 10 08:46:51 2003
From: yweng@cs.uoregon.edu (Yan Weng)
Date: Tue, 10 Jun 2003 00:46:51 -0700
Subject: [Python-Dev] Can we switch different "byte code interpreters"?
In-Reply-To: <20030610001118.B3788@tibia.amotlpaa.bogus>
Message-ID: <000b01c32f24$89ac89a0$b9acdf80@uo0b0aw1s4pcg0>

Hi, all, 

I am new to Python's core. I have a question here. Is the "byte code
interpreter" part implemented as a separate part, say, a dll or so?
If not, why?

The advantage to make interpreter a "plug-in" like module is:
We can test different interpreter implementations or optimizers easily.





From Paul.Moore@atosorigin.com  Tue Jun 10 09:14:10 2003
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Tue, 10 Jun 2003 09:14:10 +0100
Subject: [Python-Dev] Re: PEP-317
Message-ID: <16E1010E4581B049ABC51D4975CEDB880113DB4A@UKDCX001.uk.int.atosorigin.com>

From: Steven Taschuk [mailto:staschuk@telusplanet.net]
> 2. The run-time warnings are issued when raising an exception;
> also not usually on a performance-critical path.  (Except for
> things like StopIteration.  But the PEP does not propose any
> change to the C API, so the built-in iterators won't be affected.)

But the runtime check has to be done for all uses of the raise
statement, so that the penalty is incurred not only by people who
haven't changed their code but also by those who have. It's a
pity that people who have done what is required still get penalised.

That's in the nature of runtime warnings, but nevertheless shouldn't
be ignored.

Paul


From mal@lemburg.com  Tue Jun 10 09:26:46 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Jun 2003 10:26:46 +0200
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <20030609191821.GA22026@glacier.arctrix.com>
References: <20030609191821.GA22026@glacier.arctrix.com>
Message-ID: <3EE59646.8050705@lemburg.com>

Neil Schemenauer wrote:
> The goal is that the compiler should be able to determine the scope of a
> name at compile time.  Code like the above does not allow that and so
> non-local names must be searched for in both globals and builtins at run
> time.  Unfortunately the warning is not bulletproof.  It's possible to
> modify the module dict directly and bypass the warning.  I'm not sure
> what to do about that. :-(
 >
> Eventually we might want to allow optimizations based on known builtin
> functions.  For example, code like
> 
>     for i in range(100000):
>         ...
> 
> could be rewritten to use an integer counter rather than creating a list
> and then iterating over it.  I'm not sure how much resistance there
> would be in the community to disallowing reassignment of builtin names
> though.  I don't think I've ever reassigned a builtin name so I think it
> would be worth it.

All very nice, but you'll have to think about two cases which
could cause trouble:

1. Extending builtins should still be possible like it is now.

    Of course, the extensions wouldn't take part in the optimizations
    you have in mind, but they should still be found.

2. What happens if a new Python version introduces new builtins
    that are in use by some modules out there for other purposes ?

    The problem here is similar to that of introducing new keywords.
    Modules should still be able to override builtin names in their
    globals; directly, via the global statement and also dynamically
    (modules are often used as container for global variables and
    state).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 10 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        14 days left



From zen@shangri-la.dropbear.id.au  Tue Jun 10 09:46:18 2003
From: zen@shangri-la.dropbear.id.au (Stuart Bishop)
Date: Tue, 10 Jun 2003 18:46:18 +1000
Subject: [Python-Dev] Re: [DB-SIG] API suggestion: expose 'quote' method
In-Reply-To: <3EDF100C.6040903@lemburg.com>
Message-ID: <009886AF-9B20-11D7-819D-000A95A06FC6@shangri-la.dropbear.id.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=0D
On Thursday, June 5, 2003, at 07:40  PM, M.-A. Lemburg wrote:=0D
=0D
> Magnus Lyck=E5 wrote:=0D
>> At 17:18 2003-06-04 -0700, Chris Cogdon wrote:=0D
>>> So, perhaps what I really should be asking for is to include a =0D
>>> specification for an interface, such as what I've suggested before, =0D=

>>> but make that a OPTIONAL part of the specification. Ie, if it's easy =
=0D
>>> enough to expose, then the driver writers should expose it in the =0D=

>>> standard form.=0D
>>>=0D
>>> Does THAT sound reasonable ?=0D
>> Certainly. Many drivers implement things beyond the mandatory=0D
>> standard, and if it's possible to get the extras compatible=0D
>> across drivers, that's a big bonus in my opinion.=0D
>=0D
> No objection to adding a note to the spec about this. I still=0D
> think that you have to flesh out a reasonable API for this,=0D
> though, e.g. quoting should implemented on a per data type=0D
> basis rather than on a per SQL statement basis.=0D
=0D
Here is a starting point, stolen from Perl's DBI spec (which has=0D
had a fully functional quote method for almost a decade...)=0D
=0D
Translated into Python to avoid abuse ;)=0D
=0D
quote(value)=0D
=0D
     Quote a value for use as a literal value in an SQL statement,=0D
     by escaping any special characters (such as quotation marks) =0D
contained=0D
     within the string and adding the required type of outer quotation =0D=

marks=0D
=0D
     ::=0D
=0D
         >>> 'SELECT foo FROM bar WHERE baz =3D %s' % =
(con.quote("Don't"))=0D
         "SELECT foo FROM bar WHERE baz =3D 'Don''t'"=0D
=0D
     For most database types, quote would return ``'Dont''t'``=0D
     (including the outer quotation marks).=0D
=0D
     A value of ``None`` will be returned as the string ``NULL`` to=0D
     match how NULLs are represented in SQL.=0D
=0D
     Quote will probably *not* be able to deal with all possible input=0D=

     (such as binary data or data containing newlines), and is not =0D
related in=0D
     any way with escaping shell meta-characters. There is no need to =0D=

quote=0D
     values being passed as bound parameters to the ``execute`` or=0D
     ``executemany`` methods.=0D
=0D
quoteidentifier(name)=0D
quoteidentifier(schema, table)=0D
quoteidentifier(catalog, schema, table)=0D
=0D
     Quote an idenntifier (table name etc.) for use in an SQL statement,=0D=

     by escaping any special characters (such as double quotation marks)=0D=

     it contains and adding the required type of outer quotation marks.=0D=

=0D
     Undefined names are ignored and the remainder are quoted and then=0D=

     joined together, typically with a dot (``.``) character. For =0D
example::=0D
=0D
         con.quoteidentifier(None, 'Her schema', 'My table')=0D
=0D
     would, for most database types, return ``"Her schema"."My table"``=0D=

     (including all the double quotation marks).=0D
=0D
     If three names are supplied then the first is assumed to be a =0D
catalog=0D
     name. For example, for Oracle::=0D
=0D
         >>> con.quoteidentifier('link', 'schema', 'table')=0D
         "schema"."table"@"link"=0D
=0D
- -- =0D
Stuart Bishop <zen@shangri-la.dropbear.id.au>=0D
http://shangri-la.dropbear.id.au/=0D
=0D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE+5Zrgh8iUz1x5geARAmi2AJ9DFepNqmCakqhErOXkzCANynzXqwCgniQ9
KA6ggg4WGHl8gxuvcMzVNFA=3D
=3DGMpq
-----END PGP SIGNATURE-----



From mwh@python.net  Tue Jun 10 12:51:17 2003
From: mwh@python.net (Michael Hudson)
Date: Tue, 10 Jun 2003 12:51:17 +0100
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <5.1.1.6.0.20030609185440.022210a0@telecommunity.com> ("Phillip
 J. Eby"'s message of "Mon, 09 Jun 2003 18:55:14 -0400")
References: <200306091903.h59J38Y09921@odiug.zope.com>
 <5.1.1.6.0.20030609185440.022210a0@telecommunity.com>
Message-ID: <2misregngq.fsf@starship.python.net>

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

> At 10:48 AM 6/10/03 +1200, Greg Ewing wrote:
>> > I don't have a use case that breaks with this requirement (since you
>> > can always use multiple inheritance to make a desirable class
>> > raisable).
>>
>>What if the desirable class has a C layout that conflicts
>>with that of Exception?
>
> Can't Exception be "abstract" with respect to layout?

Already is:

>>> class EL(list, Exception):
...  pass
... 
>>> issubclass(EL, list)
True
>>> issubclass(EL, Exception)
True

Exception and its subclasses are bona-fide old-style classes.  The
fact that they happen to be implemented in C doesn't change that.

Cheers,
M.

-- 
  This is an off-the-top-of-the-head-and-not-quite-sober suggestion,
  so is probably technically laughable.  I'll see how embarassed I
  feel tomorrow morning.            -- Patrick Gosling, ucam.comp.misc


From mwh@python.net  Tue Jun 10 13:08:51 2003
From: mwh@python.net (Michael Hudson)
Date: Tue, 10 Jun 2003 13:08:51 +0100
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <20030609191821.GA22026@glacier.arctrix.com> (Neil
 Schemenauer's message of "Mon, 9 Jun 2003 12:18:21 -0700")
References: <20030609191821.GA22026@glacier.arctrix.com>
Message-ID: <2mel22gmng.fsf@starship.python.net>

Neil Schemenauer <nas@python.ca> writes:

> I'm not sure how much resistance there would be in the community to
> disallowing reassignment of builtin names though.  I don't think
> I've ever reassigned a builtin name so I think it would be worth it.

I'm not sure quite what you mean here, but I had plenty of variables
called `file' pre-2.2 (and probably still do).

Cheers,
M.

-- 
  Every day I send overnight packages filled with rabid weasels to
  people who use frames for no good reason.
                             -- The Usenet Oracle, Oracularity #1017-1


From guido@python.org  Tue Jun 10 14:51:15 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 09:51:15 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Tue, 10 Jun 2003 10:26:46 +0200."
 <3EE59646.8050705@lemburg.com>
References: <20030609191821.GA22026@glacier.arctrix.com>
 <3EE59646.8050705@lemburg.com>
Message-ID: <200306101351.h5ADpFT12507@odiug.zope.com>

> 1. Extending builtins should still be possible like it is now.
> 
>     Of course, the extensions wouldn't take part in the optimizations
>     you have in mind, but they should still be found.

I'm not sure what you mean by "extending builtins", but if it is what
I think it is, I am strongly opposed.  The builtins should have fixed
capabilities (in a particular Python version).  If you want a function
that behaves just like a builtin but also can do something else, give
it a different name and import it explicitly, don't override the
existing entry in __builtin__.  If you have a new function that you
want to use in lots of code, resist the temptation to add it to the
__builtin__ module.  Zope did this e.g. with get_transaction() and the
net result was reader confusion and intractable dependencies on import
order.

> 2. What happens if a new Python version introduces new builtins
>     that are in use by some modules out there for other purposes ?

*** THIS IS NOT AFFECTED! ***

There is no proposal on the table to ban the use of identifiers known
to be built-ins for any purpose.  If a module defines a class,
function or variable that shadows a builtin name, that's fine, because
the parser has no problem detecting this situation.

The *only* thing being banned is insertion of a new name that shadows
a builtin from outside a module.

IOW:

  # module foo
  def open(): return ...

is fine, but

  import foo
  foo.open = 42

is not.

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


From mcherm@mcherm.com  Tue Jun 10 14:52:10 2003
From: mcherm@mcherm.com (Michael Chermside)
Date: Tue, 10 Jun 2003 06:52:10 -0700
Subject: [Python-Dev] RE: PEP-317
Message-ID: <1055253130.3ee5e28ab7650@mcherm.com>

Greg Ewing:
> Also while we're at it, how about storing the traceback in the
> exception object, and getting rid of sys.exc_info() etc.?

Guido:
> That's a good idea, and I'd support a PEP on that topic more than PEP
> 317 (which IMO is unnecessary).

IMO the biggest advantage of PEP 317 is not what it does directly but the
future enhancements it allows. If all exceptions really are objects, 
(particularly if strengthened to say "instances of Exception or subclasses")
then we can add new features to Exception. Moving the traceback into
the object is one idea. Making Exception a new-style object is another
(no need to rush, but it'll happen SOMEDAY, right?). Exception
chaining (aka exception masking) is another.

The point is, without PEP 317, you can't do these things, because sometimes
you use an object, and sometimes just mention a class (and sometimes just
use a string). PEP 317 choose not to try to bite off anything bigger than
fixing this so future enhancements would be possible. But we EVER want
these kinds of enhancements, then start a PEP 317 style migration NOW,
because degree of code breakage means that the migration time will be really
slow. Deprecating (ideally with warnings) sooner is better.

-- Michael Chermside



From aahz@pythoncraft.com  Tue Jun 10 14:37:07 2003
From: aahz@pythoncraft.com (Aahz)
Date: Tue, 10 Jun 2003 09:37:07 -0400
Subject: [Python-Dev] Can we switch different "byte code interpreters"?
In-Reply-To: <000b01c32f24$89ac89a0$b9acdf80@uo0b0aw1s4pcg0>
References: <20030610001118.B3788@tibia.amotlpaa.bogus> <000b01c32f24$89ac89a0$b9acdf80@uo0b0aw1s4pcg0>
Message-ID: <20030610133707.GA21265@panix.com>

On Tue, Jun 10, 2003, Yan Weng wrote:
> 
> I am new to Python's core. I have a question here. Is the "byte code
> interpreter" part implemented as a separate part, say, a dll or so?
> If not, why?
> 
> The advantage to make interpreter a "plug-in" like module is:
> We can test different interpreter implementations or optimizers easily.

That's a complicated question; more precisely, it has a complicated
answer.  In a lot of ways, the byte code interpreter is the true core of
Python, and it's everything else that is separate (or potentially
separable).  I'd sugest that you get involved with the PyPy if you're
really interested in this topic.

http://codespeak.net/moin/pypy/
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From guido@python.org  Tue Jun 10 14:56:57 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 09:56:57 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Tue, 10 Jun 2003 13:08:51 BST."
 <2mel22gmng.fsf@starship.python.net>
References: <20030609191821.GA22026@glacier.arctrix.com>
 <2mel22gmng.fsf@starship.python.net>
Message-ID: <200306101356.h5ADuv012565@odiug.zope.com>

> > I'm not sure how much resistance there would be in the community to
> > disallowing reassignment of builtin names though.  I don't think
> > I've ever reassigned a builtin name so I think it would be worth it.
> 
> I'm not sure quite what you mean here, but I had plenty of variables
> called `file' pre-2.2 (and probably still do).

Several standard library modules export a function named 'open' as
part of their APIs.  Arguments and variables named 'dir', 'str' or
'type' are common.  And so on.

Built-ins will always be the last namespace to be searched.  The goal
here is to move this search from run time to compile time.

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


From mwh@python.net  Tue Jun 10 15:00:49 2003
From: mwh@python.net (Michael Hudson)
Date: Tue, 10 Jun 2003 15:00:49 +0100
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <1055253130.3ee5e28ab7650@mcherm.com> (Michael Chermside's
 message of "Tue, 10 Jun 2003 06:52:10 -0700")
References: <1055253130.3ee5e28ab7650@mcherm.com>
Message-ID: <2madcqghgu.fsf@starship.python.net>

Michael Chermside <mcherm@mcherm.com> writes:

> Greg Ewing:
>> Also while we're at it, how about storing the traceback in the
>> exception object, and getting rid of sys.exc_info() etc.?
>
> Guido:
>> That's a good idea, and I'd support a PEP on that topic more than PEP
>> 317 (which IMO is unnecessary).
>
> IMO the biggest advantage of PEP 317 is not what it does directly but the
> future enhancements it allows. If all exceptions really are objects, 
> (particularly if strengthened to say "instances of Exception or subclasses")
> then we can add new features to Exception. Moving the traceback into
> the object is one idea. Making Exception a new-style object is another
> (no need to rush, but it'll happen SOMEDAY, right?). Exception
> chaining (aka exception masking) is another.

But PEP 317 seems to regard removing string exceptions entirely
(something I support, possibly with a backward compatibility warning
laden shim) as a minor stepping stone on the way to removing implicit
instantiation (something I have a hard time caring about).

And as a random data point, I cannot see me stopping typing e.g.

raise TypeError, 'must set field "%s" to "%s", not "%s"'%(fname, reqt, gott)

until Python shouts at me each and every time I do it.  Some habits
die hard[1].

> The point is, without PEP 317, you can't do these things, because sometimes
> you use an object, and sometimes just mention a class (and sometimes just
> use a string). PEP 317 choose not to try to bite off anything bigger than
> fixing this so future enhancements would be possible. But we EVER want
> these kinds of enhancements, then start a PEP 317 style migration NOW,
> because degree of code breakage means that the migration time will be really
> slow. Deprecating (ideally with warnings) sooner is better.

I don't see how removing implicit instantiation makes this easier.

Cheers,
M.
... who would also like to see restartable exceptions, but isn't going
to mention that today, oh no ...

[1] I never got *into* the habit of using string exceptions, and in
    fact still don't quite understand what happens when you try and
    catch one (this is not an invitation for an explanation).

-- 
  ... but I guess there are some things that are so gross you just have
  to forget, or it'll destroy something within you.  perl is the first
  such thing I have known.              -- Erik Naggum, comp.lang.lisp


From just@letterror.com  Tue Jun 10 15:01:43 2003
From: just@letterror.com (Just van Rossum)
Date: Tue, 10 Jun 2003 16:01:43 +0200
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <200306101351.h5ADpFT12507@odiug.zope.com>
Message-ID: <r01050400-1026-142A33A79B4C11D7ABF2003065D5E7E4@[10.0.0.23]>

Guido van Rossum wrote:

> IOW:
> 
>   # module foo
>   def open(): return ...
> 
> is fine, but
> 
>   import foo
>   foo.open = 42
> 
> is not.

How about this:

  # module foo
  def open(): ...
  
  # module bar
  import foo
  foo.open = 42

?

(I would assume it to be ok, since the builtin name was already
shadowed.)

Just


From pedronis@bluewin.ch  Tue Jun 10 15:04:43 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Tue, 10 Jun 2003 16:04:43 +0200
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <3EE59646.8050705@lemburg.com>
References: <20030609191821.GA22026@glacier.arctrix.com>
 <20030609191821.GA22026@glacier.arctrix.com>
Message-ID: <5.2.1.1.0.20030610155201.025eca30@pop.bluewin.ch>

At 10:26 10.06.2003 +0200, M.-A. Lemburg wrote:

>    (modules are often used as container for global variables and
>    state).


and that kind of usage is penalized maybe too much by the patch as it 
stands: e.g
[probably an application scripting scenario]

import new
import sys

userdata = new.module('userdata')
execfile('startupdata',userdata.__dict__)

sys.modules['userdata'] = userdata


user scripts:

import userdata

userdata.x=...


regards 



From guido@python.org  Tue Jun 10 15:11:32 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 10:11:32 -0400
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: Your message of "Tue, 10 Jun 2003 06:52:10 PDT."
 <1055253130.3ee5e28ab7650@mcherm.com>
References: <1055253130.3ee5e28ab7650@mcherm.com>
Message-ID: <200306101411.h5AEBWg13102@odiug.zope.com>

> Greg Ewing:
> > Also while we're at it, how about storing the traceback in the
> > exception object, and getting rid of sys.exc_info() etc.?
> 
> Guido:
> > That's a good idea, and I'd support a PEP on that topic more than PEP
> > 317 (which IMO is unnecessary).

Michael Chermside:
> IMO the biggest advantage of PEP 317 is not what it does directly but the
> future enhancements it allows. If all exceptions really are objects, 
> (particularly if strengthened to say "instances of Exception or subclasses")
> then we can add new features to Exception. Moving the traceback into
> the object is one idea. Making Exception a new-style object is another
> (no need to rush, but it'll happen SOMEDAY, right?). Exception
> chaining (aka exception masking) is another.
> 
> The point is, without PEP 317, you can't do these things, because sometimes
> you use an object, and sometimes just mention a class (and sometimes just
> use a string). PEP 317 choose not to try to bite off anything bigger than
> fixing this so future enhancements would be possible. But we EVER want
> these kinds of enhancements, then start a PEP 317 style migration NOW,
> because degree of code breakage means that the migration time will be really
> slow. Deprecating (ideally with warnings) sooner is better.

There seem to be lots of different things in that PEP (I've got no
time to read it in full).

- deprecating string exceptions: definitely

- making all exceptions derive from Exception: most probably

- making Exception a new-style class: eventually

But I'm not at all happy with the proposed deprecation of

  raise Class

and

  raise Class, arguments

in favor of

  raise Class()

and

  raise Class(arguments)

I don't see how this change is necessary in order to get any of the
other benefits.

I also don't understand the commotion over deferred exception
instantiation, since it doesn't happen except for exceptions
raised from C code.

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


From guido@python.org  Tue Jun 10 15:16:47 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 10:16:47 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Tue, 10 Jun 2003 16:01:43 +0200."
 <r01050400-1026-142A33A79B4C11D7ABF2003065D5E7E4@[10.0.0.23]>
References: <r01050400-1026-142A33A79B4C11D7ABF2003065D5E7E4@[10.0.0.23]>
Message-ID: <200306101416.h5AEGlr13154@odiug.zope.com>

> Guido van Rossum wrote:
> 
> > IOW:
> > 
> >   # module foo
> >   def open(): return ...
> > 
> > is fine, but
> > 
> >   import foo
> >   foo.open = 42
> > 
> > is not.
> 
> How about this:
> 
>   # module foo
>   def open(): ...
>   
>   # module bar
>   import foo
>   foo.open = 42
> 
> ?
> 
> (I would assume it to be ok, since the builtin name was already
> shadowed.)

Yes, this wouldn't break in any new ways due to the proposed
optimization, and you won't get the warning because it only warns
about inserting new names.

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



From pedronis@bluewin.ch  Tue Jun 10 15:03:06 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Tue, 10 Jun 2003 16:03:06 +0200
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <200306101351.h5ADpFT12507@odiug.zope.com>
References: <Your message of "Tue, 10 Jun 2003 10:26:46 +0200." <3EE59646.8050705@lemburg.com>
 <20030609191821.GA22026@glacier.arctrix.com>
 <3EE59646.8050705@lemburg.com>
Message-ID: <5.2.1.1.0.20030610160039.025f2de8@pop.bluewin.ch>

At 09:51 10.06.2003 -0400, Guido van Rossum wrote:
> > 1. Extending builtins should still be possible like it is now.
> >
> >     Of course, the extensions wouldn't take part in the optimizations
> >     you have in mind, but they should still be found.
>
>I'm not sure what you mean by "extending builtins", but if it is what
>I think it is, I am strongly opposed.  The builtins should have fixed
>capabilities (in a particular Python version).  If you want a function
>that behaves just like a builtin but also can do something else, give
>it a different name and import it explicitly, don't override the
>existing entry in __builtin__.  If you have a new function that you
>want to use in lots of code, resist the temptation to add it to the
>__builtin__ module.  Zope did this e.g. with get_transaction() and the
>net result was reader confusion and intractable dependencies on import
>order.
>

what about substituing the built-in entirely for security reasons,
Zope3 does that with its wrapping versions:


     def ri_exec(self, code):
         # XXX What is the type of code?
         self.globals['__builtins__'] = RestrictedBuiltins
         exec code in self.globals

regards. 



From guido@python.org  Tue Jun 10 15:21:56 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 10:21:56 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Tue, 10 Jun 2003 16:03:06 +0200."
 <5.2.1.1.0.20030610160039.025f2de8@pop.bluewin.ch>
References: <Your message of "Tue, 10 Jun 2003 10:26:46 +0200." <3EE59646.8050705@lemburg.com> <20030609191821.GA22026@glacier.arctrix.com> <3EE59646.8050705@lemburg.com>
 <5.2.1.1.0.20030610160039.025f2de8@pop.bluewin.ch>
Message-ID: <200306101421.h5AELuo13212@odiug.zope.com>

> what about substituing the built-in entirely for security reasons,
> Zope3 does that with its wrapping versions:
> 
> 
>      def ri_exec(self, code):
>          # XXX What is the type of code?
>          self.globals['__builtins__'] = RestrictedBuiltins
>          exec code in self.globals
> 
> regards. 

Restricted execution is a different case; possibly the compiler will
need to know when it is compiling for restricted mode.

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


From aahz@pythoncraft.com  Tue Jun 10 15:23:02 2003
From: aahz@pythoncraft.com (Aahz)
Date: Tue, 10 Jun 2003 10:23:02 -0400
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <200306101411.h5AEBWg13102@odiug.zope.com>
References: <1055253130.3ee5e28ab7650@mcherm.com> <200306101411.h5AEBWg13102@odiug.zope.com>
Message-ID: <20030610142302.GA26466@panix.com>

On Tue, Jun 10, 2003, Guido van Rossum wrote:
>
> But I'm not at all happy with the proposed deprecation of
> 
>   raise Class
> and
>   raise Class, arguments
> 
> in favor of
> 
>   raise Class()
> and
>   raise Class(arguments)
> 
> I don't see how this change is necessary in order to get any of the
> other benefits.

Yeah.  I've been thinking a bit, and while the proposed change makes
some sense for the case where you're passing an argument to an
exception, it makes this look uglier:

class Found(Exception):
    pass

try:
    for record in records:
        for field in record.fields:
            if data in field.data:
                raise Found()
except Found:
    # handle success
else:
    # handle failure

I find that extra set of parentheses unnecessary and ugly.  It implies a
callable where it's not really being used that way, particularly in the
asymmetry between the ``raise`` and the ``except``.  If this change goes
through, I might start doing

class Found(Exception):
    pass
Found = Found()
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From nas@python.ca  Tue Jun 10 15:36:14 2003
From: nas@python.ca (Neil Schemenauer)
Date: Tue, 10 Jun 2003 07:36:14 -0700
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <2mel22gmng.fsf@starship.python.net>
References: <20030609191821.GA22026@glacier.arctrix.com> <2mel22gmng.fsf@starship.python.net>
Message-ID: <20030610143614.GA24463@glacier.arctrix.com>

Michael Hudson wrote:
> Neil Schemenauer <nas@python.ca> writes:
> 
> > I'm not sure how much resistance there would be in the community to
> > disallowing reassignment of builtin names though.  I don't think
> > I've ever reassigned a builtin name so I think it would be worth it.
> 
> I'm not sure quite what you mean here,

What I mean by reassigning builtins is:

    import __builtin__
    __builtin__.int = something


> but I had plenty of variables called `file' pre-2.2 (and probably
> still do).

That's fine and there will be no warning.

  Neil


From sismex01@hebmex.com  Tue Jun 10 15:26:34 2003
From: sismex01@hebmex.com (sismex01@hebmex.com)
Date: Tue, 10 Jun 2003 09:26:34 -0500
Subject: [Python-Dev] RE: PEP-317
Message-ID: <F7DB8D13DB61D511B6FF00B0D0F062330506F844@mail.hebmex.com>

> From: Aahz [mailto:aahz@pythoncraft.com]
> Sent: Tuesday, June 10, 2003 9:23 AM
> 
> Yeah.  I've been thinking a bit, and while the proposed change makes
> some sense for the case where you're passing an argument to an
> exception, it makes this look uglier:
> 
> class Found(Exception):
>     pass
> 
> try:
>     for record in records:
>         for field in record.fields:
>             if data in field.data:
>                 raise Found()
> except Found:
>     # handle success
> else:
>     # handle failure
> 
> I find that extra set of parentheses unnecessary and ugly.  
> It implies a callable where it's not really being used that
> way, particularly in the asymmetry between the ``raise`` and
> the ``except``.
>

On the other hand, I read it quite clear; the extra set
of parenthesis you find so ugly, imply to me that an
instance of Found is being raised, and that except: is
going to catch all instances of Found.  It's a matter
of taste, that you (aesthetically) like it or not,
but it's a matter of consistency and correctness that
it should be there or not.

>
> If this change goes through, I might start doing
> 
> class Found(Exception):
>     pass
> Found = Found()
>

You won't catch anything in that case, check this out:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help

>>> class Found(Exception):
	pass

>>> Found = Found()
>>> def fnEx():
	try:
		print "Fire in the hole!"
		raise Found
	except Found:
		print "Fire extinguished."

		
>>> 
>>> 
>>> fnEx()
Fire in the hole!
Traceback (most recent call last):
  File "<pyshell#21>", line 1, in ?
    fnEx()
  File "<pyshell#18>", line 4, in fnEx
    raise Found
Found
>>> 
>>> isinstance(Found,Found)
Traceback (most recent call last):
  File "<pyshell#22>", line 1, in ?
    isinstance(Found,Found)
TypeError: isinstance() arg 2 must be a class or type
>>> 


You can't catch instances of the Found.__class__
by referring to Found, you'd have to do something
like this:


>>> 
>>> def fnEx():
	try:
		print "Fire in the hole!"
		raise Found
	except Found.__class__:
		print "Caught."

		
>>> 
>>> fnEx()
Fire in the hole!
Caught.
>>> 


There it did get caught, but it seems quite uglier
than an extra pair of parenthesis.

just my 2 cents.

-gca

pd: Please excuse this unnecessary, hideous and wasteful
    legalese. :-(
--
Advertencia:La informacion contenida en este mensaje es confidencial y
restringida, por lo tanto esta destinada unicamente para el uso de la
persona arriba indicada, se le notifica que esta prohibida la difusion de
este mensaje. Si ha recibido este mensaje por error, o si hay problemas en
la transmision, favor de comunicarse con el remitente. Gracias.


From mwh@python.net  Tue Jun 10 15:39:32 2003
From: mwh@python.net (Michael Hudson)
Date: Tue, 10 Jun 2003 15:39:32 +0100
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <20030610143614.GA24463@glacier.arctrix.com> (Neil
 Schemenauer's message of "Tue, 10 Jun 2003 07:36:14 -0700")
References: <20030609191821.GA22026@glacier.arctrix.com>
 <2mel22gmng.fsf@starship.python.net>
 <20030610143614.GA24463@glacier.arctrix.com>
Message-ID: <2m4r2ygfob.fsf@starship.python.net>

Neil Schemenauer <nas@python.ca> writes:

> Michael Hudson wrote:
>> Neil Schemenauer <nas@python.ca> writes:
>> 
>> > I'm not sure how much resistance there would be in the community to
>> > disallowing reassignment of builtin names though.  I don't think
>> > I've ever reassigned a builtin name so I think it would be worth it.
>> 
>> I'm not sure quite what you mean here,
>
> What I mean by reassigning builtins is:
>
>     import __builtin__
>     __builtin__.int = something
>

Ah.  I think Guido dislikes this one (as in, would like to see this
practice banned), not sure about the community :-)

>> but I had plenty of variables called `file' pre-2.2 (and probably
>> still do).
>
> That's fine and there will be no warning.

Goody.

Cheers,
M.

-- 
  [3] Modem speeds being what they are, large .avi files were
      generally downloaded to the shell server instead[4].
  [4] Where they were usually found by the technical staff, and
      burned to CD.                                   -- Carlfish, asr


From barry@python.org  Tue Jun 10 15:43:31 2003
From: barry@python.org (Barry Warsaw)
Date: 10 Jun 2003 10:43:31 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <20030610143614.GA24463@glacier.arctrix.com>
References: <20030609191821.GA22026@glacier.arctrix.com>
 <2mel22gmng.fsf@starship.python.net>
 <20030610143614.GA24463@glacier.arctrix.com>
Message-ID: <1055256210.9634.5.camel@barry>

On Tue, 2003-06-10 at 10:36, Neil Schemenauer wrote:

> What I mean by reassigning builtins is:
> 
>     import __builtin__
>     __builtin__.int = something

IMO the only defensible reason to do that is for debugging purposes. 
Although I haven't had a need for this in many years, it has
occasionally been useful to reassign built-in open() to catch or log a
particular file action.  (IIRC, the last time I did this was before the
resulting IOError included the filename argument.)

A warning is fine -- even desirable.  I'd want to make sure such
debugging hacks didn't make it into a release. :)

-Barry




From mal@lemburg.com  Tue Jun 10 15:32:41 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Jun 2003 16:32:41 +0200
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <200306101351.h5ADpFT12507@odiug.zope.com>
References: <20030609191821.GA22026@glacier.arctrix.com>              <3EE59646.8050705@lemburg.com> <200306101351.h5ADpFT12507@odiug.zope.com>
Message-ID: <3EE5EC09.1070600@lemburg.com>

Guido van Rossum wrote:
>>1. Extending builtins should still be possible like it is now.
>>
>>    Of course, the extensions wouldn't take part in the optimizations
>>    you have in mind, but they should still be found.
> 
> 
> I'm not sure what you mean by "extending builtins", but if it is what
> I think it is, I am strongly opposed.  The builtins should have fixed
> capabilities (in a particular Python version).  If you want a function
> that behaves just like a builtin but also can do something else, give
> it a different name and import it explicitly, don't override the
> existing entry in __builtin__.  If you have a new function that you
> want to use in lots of code, resist the temptation to add it to the
> __builtin__ module.  Zope did this e.g. with get_transaction() and the
> net result was reader confusion and intractable dependencies on import
> order.

I am talking about what mxTools is doing: adding new builtins to
the interpreter by placing them into the __builtins__ dictionary.
While I agree that it is usually better to use something like
'from x import *' or even naming the tools explicitly, some features
in mxTools do warrant being made builtins, e.g. irange() has been
most helpful in the past :-)

Note that I'm not talking about overriding existing builtins. mxTools
just adds a few more (that's what I meant with "extending builtins").

>>2. What happens if a new Python version introduces new builtins
>>    that are in use by some modules out there for other purposes ?
> 
> *** THIS IS NOT AFFECTED! ***
> 
> There is no proposal on the table to ban the use of identifiers known
> to be built-ins for any purpose.  If a module defines a class,
> function or variable that shadows a builtin name, that's fine, because
> the parser has no problem detecting this situation.
> 
> The *only* thing being banned is insertion of a new name that shadows
> a builtin from outside a module.
> 
> IOW:
> 
>   # module foo
>   def open(): return ...
> 
> is fine, but
> 
>   import foo
>   foo.open = 42
> 
> is not.

I presume you mean the case that foo.open is not already defined in
foo. That's good.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 10 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        14 days left



From guido@python.org  Tue Jun 10 15:44:56 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 10:44:56 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Tue, 10 Jun 2003 15:39:32 BST."
 <2m4r2ygfob.fsf@starship.python.net>
References: <20030609191821.GA22026@glacier.arctrix.com> <2mel22gmng.fsf@starship.python.net> <20030610143614.GA24463@glacier.arctrix.com>
 <2m4r2ygfob.fsf@starship.python.net>
Message-ID: <200306101444.h5AEiuF14382@odiug.zope.com>

> >     import __builtin__
> >     __builtin__.int = something
> 
> Ah.  I think Guido dislikes this one (as in, would like to see this
> practice banned), not sure about the community :-)

Indeed, I strongly dislike this, because the scope of the change is
the entire Python process.  Sooner or later this practice will cause
someone to rely on a change to a built-in that breaks a standard
library module that they didn't even know they were relying on.

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


From guido@python.org  Tue Jun 10 15:48:28 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 10:48:28 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Tue, 10 Jun 2003 16:32:41 +0200."
 <3EE5EC09.1070600@lemburg.com>
References: <20030609191821.GA22026@glacier.arctrix.com> <3EE59646.8050705@lemburg.com> <200306101351.h5ADpFT12507@odiug.zope.com>
 <3EE5EC09.1070600@lemburg.com>
Message-ID: <200306101448.h5AEmSN14701@odiug.zope.com>

> I am talking about what mxTools is doing: adding new builtins to
> the interpreter by placing them into the __builtins__ dictionary.
> While I agree that it is usually better to use something like
> 'from x import *' or even naming the tools explicitly, some features
> in mxTools do warrant being made builtins, e.g. irange() has been
> most helpful in the past :-)

You're not going to convince me to endorse that practice.  End of story.

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


From mal@lemburg.com  Tue Jun 10 15:55:24 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 10 Jun 2003 16:55:24 +0200
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <200306101448.h5AEmSN14701@odiug.zope.com>
References: <20030609191821.GA22026@glacier.arctrix.com>	<3EE59646.8050705@lemburg.com> <200306101351.h5ADpFT12507@odiug.zope.com>  	<3EE5EC09.1070600@lemburg.com> <200306101448.h5AEmSN14701@odiug.zope.com>
Message-ID: <3EE5F15C.6040104@lemburg.com>

Guido van Rossum wrote:
>>I am talking about what mxTools is doing: adding new builtins to
>>the interpreter by placing them into the __builtins__ dictionary.
>>While I agree that it is usually better to use something like
>>'from x import *' or even naming the tools explicitly, some features
>>in mxTools do warrant being made builtins, e.g. irange() has been
>>most helpful in the past :-)
> 
> You're not going to convince me to endorse that practice.  End of story.

I'm not asking you for endorsement :-) Just wanted to note that
Python's dynamic features are actually being used in this case
(and have been for years).

BTW, I don't see any problem with optimizing the builtins
access regardeless of whether adding builtins is considered good
or bad. Caching the lookups for globals in code objects seems like
a good way to increase performance without having to change a single
line of code and builtins a great candidate for cacheable
globals (I'd even make all functions and classes at module
top-level cacheable per default if Python is run under -OO).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 10 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        14 days left



From jacobs@penguin.theopalgroup.com  Tue Jun 10 15:56:58 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Tue, 10 Jun 2003 10:56:58 -0400 (EDT)
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <200306101448.h5AEmSN14701@odiug.zope.com>
Message-ID: <Pine.LNX.4.44.0306101050490.16127-100000@penguin.theopalgroup.com>

On Tue, 10 Jun 2003, Guido van Rossum wrote:
> > I am talking about what mxTools is doing: adding new builtins to
> > the interpreter by placing them into the __builtins__ dictionary.
> > While I agree that it is usually better to use something like
> > 'from x import *' or even naming the tools explicitly, some features
> > in mxTools do warrant being made builtins, e.g. irange() has been
> > most helpful in the past :-)
> 
> You're not going to convince me to endorse that practice.  End of story.

While not trying to convince you, I do have to say that we use this trick to
provide implementations of builtins to code running under older Python
versions.  This allows us to write code using useful features from Python
2.3 like enumerate, sum, basestring, etc. that can run under Python 2.2. 
For example:

  def export(name, obj):
    import __builtin__
    setattr(__builtin__,name,obj)

  try:
    enumerate

  except NameError:

    def enumerate(l):
      '''Given a sequence l, generates an indexed series:  (0,l[0]), (1,l[1])...'''
      i = 0
      next = iter(l).next
      while 1:
        yield (i, next())
        i += 1

    export('enumerate',enumerate)
 
It isn't the prettiest thing, but it does get the job done.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From guido@python.org  Tue Jun 10 16:03:15 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 11:03:15 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Tue, 10 Jun 2003 10:56:58 EDT."
 <Pine.LNX.4.44.0306101050490.16127-100000@penguin.theopalgroup.com>
References: <Pine.LNX.4.44.0306101050490.16127-100000@penguin.theopalgroup.com>
Message-ID: <200306101503.h5AF3Gl16386@odiug.zope.com>

> While not trying to convince you, I do have to say that we use this
> trick to provide implementations of builtins to code running under
> older Python versions.

Whatever works for a given Python version works.  Going forward,
builtins may become more static than they currently are (but only if
the performance benefits turn out to be really worth it).

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


From jacobs@penguin.theopalgroup.com  Tue Jun 10 16:10:18 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Tue, 10 Jun 2003 11:10:18 -0400 (EDT)
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <200306101503.h5AF3Gl16386@odiug.zope.com>
Message-ID: <Pine.LNX.4.44.0306101105400.16735-100000@penguin.theopalgroup.com>

On Tue, 10 Jun 2003, Guido van Rossum wrote:
> > While not trying to convince you, I do have to say that we use this
> > trick to provide implementations of builtins to code running under
> > older Python versions.
> 
> Whatever works for a given Python version works.  Going forward,
> builtins may become more static than they currently are (but only if
> the performance benefits turn out to be really worth it).

I understand, though I suppose I'd still like to have the option of a
dynamic builtin namespace as a fallback to a new fast/static builtin
namespace.  Either that or we go all out and get rid of all builtins in
Python 3K, though I'm not sure how much I'd like typing 
'from System.Types import None', etc. in every file.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From staschuk@telusplanet.net  Tue Jun 10 16:10:11 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Tue, 10 Jun 2003 09:10:11 -0600
Subject: [Python-Dev] PEP-317
In-Reply-To: <200306100023.h5A0NdX15842@pcp02138704pcs.reston01.va.comcast.net>; from guido@python.org on Mon, Jun 09, 2003 at 08:23:39PM -0400
References: <200306092312.h59NCDK05605@oma.cosc.canterbury.ac.nz> <200306100023.h5A0NdX15842@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20030610091011.B374@tibia.amotlpaa.bogus>

Quoth Guido van Rossum:
  [...]
> That's a good idea, and I'd support a PEP on that topic more than PEP
> 317 (which IMO is unnecessary).

I agree it's unnecessary; even the bit about eliminating string
exceptions is unnecessary.  But I thought the important question
was whether the proposal represents a net improvement to the
language and can be achieved with acceptable migration pain.

Raymond's arguing the "excessive migration pain" angle quite well,
and if the PEP is to be accepted, I'll certainly have to make a
more convincing counter-argument on this point than I have so far.

I haven't seen any claim that it's a net worsening of the
language, though some feel the improvement is negligible.  (I
don't think I can change their minds if the PEP's existing
motivation text doesn't.)

But merely being unnecessary seems a weak criterion for rejection.

-- 
Steven Taschuk             "[W]e must be very careful when we give advice
staschuk@telusplanet.net    to younger people: sometimes they follow it!"
                             -- "The Humble Programmer", Edsger Dijkstra


From staschuk@telusplanet.net  Tue Jun 10 15:51:57 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Tue, 10 Jun 2003 08:51:57 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <16E1010E4581B049ABC51D4975CEDB880113DB4A@UKDCX001.uk.int.atosorigin.com>; from Paul.Moore@atosorigin.com on Tue, Jun 10, 2003 at 09:14:10AM +0100
References: <16E1010E4581B049ABC51D4975CEDB880113DB4A@UKDCX001.uk.int.atosorigin.com>
Message-ID: <20030610085157.A374@tibia.amotlpaa.bogus>

Quoth Moore, Paul:
  [...]
> But the runtime check has to be done for all uses of the raise
> statement, so that the penalty is incurred not only by people who
> haven't changed their code but also by those who have. [...]

True -- but the present implementation of 'raise' already does the
relevant type-checking: it checks whether a string is being raised
so it can decide whether to issue a PendingDeprecationWarning; it
checks whether a class is being raised so it can decide whether to
implicit instantiate.  (And, of course, any implementation would
have to do *some* type checking in order to decide whether to
raise a TypeError.)  So it's not a new cost.

The only new cost in PEP 317's transition period is the act of
issuing the warning itself, which is not incurred by those using
the One True Syntax, and as argued before, is not usually on a
critical path anyway.  (It is a cost, though; the next revision of
the PEP will mention it.)

(The normal case would actually be simplified under full
implementation of PEP 317, making raises slightly faster; but the
difference will be negligible, I expect, and as before, raises are
only rarely on critical paths.)

-- 
Steven Taschuk                            staschuk@telusplanet.net
"Our analysis begins with two outrageous benchmarks."
  -- "Implementation strategies for continuations", Clinger et al.


From fdrake@acm.org  Tue Jun 10 16:23:41 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Tue, 10 Jun 2003 11:23:41 -0400
Subject: [Python-Dev] PEP-317
In-Reply-To: <20030610091011.B374@tibia.amotlpaa.bogus>
References: <200306092312.h59NCDK05605@oma.cosc.canterbury.ac.nz>
 <200306100023.h5A0NdX15842@pcp02138704pcs.reston01.va.comcast.net>
 <20030610091011.B374@tibia.amotlpaa.bogus>
Message-ID: <16101.63485.561452.321806@grendel.zope.com>

Steven Taschuk writes:
 > But merely being unnecessary seems a weak criterion for rejection.

Being unnecessary while inflicting pain, however, is a good reason for
rejection.  It means people have to change code without giving them
anything.  That's bad.


  -Fred

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


From tjreedy@udel.edu  Tue Jun 10 16:25:43 2003
From: tjreedy@udel.edu (Terry Reedy)
Date: Tue, 10 Jun 2003 11:25:43 -0400
Subject: [Python-Dev] Re: Can we switch different "byte code interpreters"?
References: <20030610001118.B3788@tibia.amotlpaa.bogus> <000b01c32f24$89ac89a0$b9acdf80@uo0b0aw1s4pcg0>
Message-ID: <bc4t4u$9pb$1@main.gmane.org>

"Yan Weng" <yweng@cs.uoregon.edu> wrote in message
news:000b01c32f24$89ac89a0$b9acdf80@uo0b0aw1s4pcg0...
> I am new to Python's core. I have a question here. Is the "byte code
> interpreter" part implemented as a separate part, say, a dll or so?
> If not, why?

> The advantage to make interpreter a "plug-in" like module is:
> We can test different interpreter implementations or optimizers
easily.

I doubt that the extra time taken to link in 'everything else'
(already compiled) is the major barrier to experimenting with the byte
code interpreter ;-)  Many such experiments involve changing the byte
code itself, and hence the byte code compiler also.

Terry J. Reedy

PS.  When you start a new topic, start a new thread instead of
piggybacking on an existing thread.  Thread-aware readers typically
present a list of one line per thread and expand on request.  If I
were not reading the thread on PEP 317, I would not have seen this.





From mcherm@mcherm.com  Tue Jun 10 16:31:15 2003
From: mcherm@mcherm.com (Michael Chermside)
Date: Tue, 10 Jun 2003 08:31:15 -0700
Subject: [Python-Dev] RE: PEP-317
Message-ID: <1055259075.3ee5f9c309c74@mcherm.com>

Guido writes:
> There seem to be lots of different things in that PEP (I've got no
> time to read it in full).

Too bad... it's well written.

> - deprecating string exceptions: definitely
> 
> - making all exceptions derive from Exception: most probably

Not actually part of this PEP... the author is going for the
minimal PEP possible. But maybe it should be added.

> - making Exception a new-style class: eventually

Not really possible without this PEP.

Basically, the PEP is all about the migration plan, without
dealing much with the end point. It says "we all know string
exceptions should go. Let's also say that eventually we'll
use new-style classes, and maybe pack some extra functionality
into the Exception class. Let's start the deprecation and
warnings now." And it carefully considers all the kinds of code
breakage and how to handle it.

> But I'm not at all happy with the proposed deprecation of
> 
>   raise Class
> 
> and
> 
>   raise Class, arguments
> 
> in favor of
> 
>   raise Class()
> 
> and
> 
>   raise Class(arguments)
> 
> I don't see how this change is necessary in order to get any of the
> other benefits.

(1) There should be only one (preferably obvious) way to do it.
(2) If I write "raise x" is that an example of "raise Class", or
    of "raise instance"? With old-style exceptions, you have to
    examine the type of x to figure out what to do. With new-style
    exceptions, even that wouldn't do.
(3) The "raise Class" form has a spurious similarity with the
    except clause:
        try:
            raise MyError, raised
        except MyError, caught:
            pass
    Looks like "raised" is the same object as "caught". But it's
    not.
(4) There's no benefit to having two syntaxes. See (1).


> I also don't understand the commotion over deferred exception
> instantiation, since it doesn't happen except for exceptions
> raised from C code.

Ignore it... it's a red herring. The whole deferred exception thing
is just an implementation detail at the C level.

-- Michael Chermside



From bh@intevation.de  Tue Jun 10 16:57:23 2003
From: bh@intevation.de (Bernhard Herzog)
Date: 10 Jun 2003 17:57:23 +0200
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <Pine.LNX.4.44.0306101050490.16127-100000@penguin.theopalgroup.com>
References: <Pine.LNX.4.44.0306101050490.16127-100000@penguin.theopalgroup.com>
Message-ID: <6qr8620vto.fsf@salmakis.intevation.de>

Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:

> On Tue, 10 Jun 2003, Guido van Rossum wrote:
> > > I am talking about what mxTools is doing: adding new builtins to
> > > the interpreter by placing them into the __builtins__ dictionary.
> > > While I agree that it is usually better to use something like
> > > 'from x import *' or even naming the tools explicitly, some features
> > > in mxTools do warrant being made builtins, e.g. irange() has been
> > > most helpful in the past :-)
> > 
> > You're not going to convince me to endorse that practice.  End of story.
> 
> While not trying to convince you, I do have to say that we use this trick to
> provide implementations of builtins to code running under older Python
> versions.

There's even precedence in the standard library for modifying __builtins__:

(gettext.py, lines 219ff):

    def install(self, unicode=False):
        import __builtin__
        __builtin__.__dict__['_'] = unicode and self.ugettext or self.gettext

  Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                           http://www.mapit.de/


From guido@python.org  Tue Jun 10 16:59:06 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 11:59:06 -0400
Subject: [Python-Dev] PEP-317
In-Reply-To: Your message of "Tue, 10 Jun 2003 09:10:11 MDT."
 <20030610091011.B374@tibia.amotlpaa.bogus>
References: <200306092312.h59NCDK05605@oma.cosc.canterbury.ac.nz> <200306100023.h5A0NdX15842@pcp02138704pcs.reston01.va.comcast.net>
 <20030610091011.B374@tibia.amotlpaa.bogus>
Message-ID: <200306101559.h5AFx6d19747@odiug.zope.com>

> Guido van Rossum:
>   [...]
> > That's a good idea, and I'd support a PEP on that topic more than PEP
> > 317 (which IMO is unnecessary).

[Steven T]
> I agree it's unnecessary; even the bit about eliminating string
> exceptions is unnecessary.  But I thought the important question
> was whether the proposal represents a net improvement to the
> language and can be achieved with acceptable migration pain.

> Raymond's arguing the "excessive migration pain" angle quite well,
> and if the PEP is to be accepted, I'll certainly have to make a
> more convincing counter-argument on this point than I have so far.

I've never considered the two alternative raise syntaxes as a wart in
the language that's important enough to fix.  The predicted migration
pain seems excessive compared to the importance of the improvement.

The only case I'm willing to impose excessive migration pain to fix a
problem is when the problem is *really* unacceptable in the long run.
I've decided that's the case for int division, for the difference
between int and long, and for new-style vs. classic classes.

I don't see raise C vs. raise C() to be in the same category.

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


From guido@python.org  Tue Jun 10 17:02:53 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 12:02:53 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "10 Jun 2003 17:57:23 +0200."
 <6qr8620vto.fsf@salmakis.intevation.de>
References: <Pine.LNX.4.44.0306101050490.16127-100000@penguin.theopalgroup.com>
 <6qr8620vto.fsf@salmakis.intevation.de>
Message-ID: <200306101602.h5AG2sv20627@odiug.zope.com>

> There's even precedence in the standard library for modifying __builtins__:
> 
> (gettext.py, lines 219ff):

The standard library often goes beyond what the language standard
promises.

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


From pje@telecommunity.com  Tue Jun 10 17:04:00 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Tue, 10 Jun 2003 12:04:00 -0400
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <200306101411.h5AEBWg13102@odiug.zope.com>
References: <Your message of "Tue, 10 Jun 2003 06:52:10 PDT." <1055253130.3ee5e28ab7650@mcherm.com>
 <1055253130.3ee5e28ab7650@mcherm.com>
Message-ID: <5.1.1.6.0.20030610115951.02112810@telecommunity.com>

At 10:11 AM 6/10/03 -0400, Guido van Rossum wrote:

>But I'm not at all happy with the proposed deprecation of
>
>   raise Class
>
>and
>
>   raise Class, arguments
>
>in favor of
>
>   raise Class()
>
>and
>
>   raise Class(arguments)

You know what's really funny...  ever since Python 2.1 or thereabouts, I 
had the impression that it *had* been deprecated, and I started teaching 
myself to use the "newer" form.  I really don't remember *where* I got that 
impression though.  I did find one nice side effect, however...  It's a lot 
easier to put a helpful message in the exception if you use parentheses and 
can therefore wrap lines.  So, it turned out to be good style to do 'raise 
Class(args)' for reasons that had nothing to do with whyever I started.



From barry@python.org  Tue Jun 10 17:05:04 2003
From: barry@python.org (Barry Warsaw)
Date: 10 Jun 2003 12:05:04 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <6qr8620vto.fsf@salmakis.intevation.de>
References: <Pine.LNX.4.44.0306101050490.16127-100000@penguin.theopalgroup.com>
 <6qr8620vto.fsf@salmakis.intevation.de>
Message-ID: <1055261104.9634.13.camel@barry>

On Tue, 2003-06-10 at 11:57, Bernhard Herzog wrote:

> There's even precedence in the standard library for modifying __builtins__:
> 
> (gettext.py, lines 219ff):
> 
>     def install(self, unicode=False):
>         import __builtin__
>         __builtin__.__dict__['_'] = unicode and self.ugettext or self.gettext

Yes, but this sucks. :)

-Barry




From mcherm@mcherm.com  Tue Jun 10 17:52:17 2003
From: mcherm@mcherm.com (Michael Chermside)
Date: Tue, 10 Jun 2003 09:52:17 -0700
Subject: [Python-Dev] RE: The Python interpreter is not fully thread-safe.
Message-ID: <1055263937.3ee60cc1de2c3@mcherm.com>

[Michael Chermside]
> Please note that what was confusing the the original poster was
> almost certainly the docs saying that "Python" was not thread-safe
> when what was really intended was, as Tim points out, that Python's
> C api was not thread safe. Using the term "free threading" is fine,
> but also make it clear that it's the _C api_ we're talking about,
> because Python itself (ie, programs coded in pure Python) _IS_
> threadsafe.

[Tim Peters]
> Not really, under most meanings of "thread safe".  For example,
> 
> """
> id = 0
> def getid():
>     global id
>     id += 1
>     return id
> """
> 
> wouldn't be considered a thread-safe way to get an id
      [...]
> Thread safety is a complicated topic
      [...]
> That's why I'd rather explain the situation than try to reduce it to
> buzzword compliance -- the buzzwords here don't have objective,
> app-independent, universally accepted meanings.

Well, you have a very good point here... just slapping the lable
"thread safe" onto it doesn't make the complexity go away. But I
still have a concern... the PHB (pointy haired boss) issue. If the
Python docs suggest that python is "not threadsafe", then the PHBs
of the world are going to say "you must use Java", since it obviously
IS threadsafe, whatever that means.

Now, I *refuse* to lower the level of discourse to that which a
PHB can comprehend. But it's worth a bit of care not to upset them.
Replacing "not threadsafe" with something equivalent to Raymond's:

   > Any library that *is* "fully thread-safe" establishes certain
   > conventions that users have to follow to achieve thread-safety. The
   > same is true for Python: if the conventions (which are elaborated in
   > section 8.1) are followed, Python is also fully thread-safe. It's just
   > that it does not support what is commonly called "free threading".

...should do admirably. It explains things for those who want to know,
but also has the key phrase "thread-safe" in it, which is all the PHB
cares about.

-- Michael Chermside

and also 


From DavidA@ActiveState.com  Tue Jun 10 18:30:51 2003
From: DavidA@ActiveState.com (David Ascher)
Date: Tue, 10 Jun 2003 10:30:51 -0700
Subject: [Python-Dev] towards a faster Python
In-Reply-To: <1055256210.9634.5.camel@barry>
References: <20030609191821.GA22026@glacier.arctrix.com>	 <2mel22gmng.fsf@starship.python.net>	 <20030610143614.GA24463@glacier.arctrix.com> <1055256210.9634.5.camel@barry>
Message-ID: <3EE615CB.1080302@ActiveState.com>

Barry Warsaw wrote:

>On Tue, 2003-06-10 at 10:36, Neil Schemenauer wrote:
>
>  
>
>>What I mean by reassigning builtins is:
>>
>>    import __builtin__
>>    __builtin__.int = something
>>    
>>
>
>IMO the only defensible reason to do that is for debugging purposes. 
>Although I haven't had a need for this in many years, it has
>occasionally been useful to reassign built-in open() to catch or log a
>particular file action.  (IIRC, the last time I did this was before the
>resulting IOError included the filename argument.)
>
I've done it to find out how often and when open() is called in a large 
application.

>A warning is fine -- even desirable.  I'd want to make sure such
>debugging hacks didn't make it into a release. :)
>  
>
In this case too, I wouldn't mind warnings.  I would mind it if I had to 
hack my libc to track python-level open() calls =).

--david



From guido@python.org  Tue Jun 10 18:37:09 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 13:37:09 -0400
Subject: [Python-Dev] towards a faster Python
In-Reply-To: Your message of "Tue, 10 Jun 2003 10:30:51 PDT."
 <3EE615CB.1080302@ActiveState.com>
References: <20030609191821.GA22026@glacier.arctrix.com> <2mel22gmng.fsf@starship.python.net> <20030610143614.GA24463@glacier.arctrix.com> <1055256210.9634.5.camel@barry>
 <3EE615CB.1080302@ActiveState.com>
Message-ID: <200306101737.h5AHb9B26098@odiug.zope.com>

> I've done it to find out how often and when open() is called in a large 
> application.
> 
> >A warning is fine -- even desirable.  I'd want to make sure such
> >debugging hacks didn't make it into a release. :)

> In this case too, I wouldn't mind warnings.  I would mind it if I had to 
> hack my libc to track python-level open() calls =).

In any case, the bytecode compiler isn't going to be able to generate
more efficient bytecode for open() calls...

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


From walter@livinglogic.de  Tue Jun 10 19:47:27 2003
From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Tue, 10 Jun 2003 20:47:27 +0200
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <20030609174558.B2982@tibia.amotlpaa.bogus>
References: <20030609145131.GA20606@epoch.metaslash.com> <200306092235.h59MZFQ05461@oma.cosc.canterbury.ac.nz> <20030609174558.B2982@tibia.amotlpaa.bogus>
Message-ID: <3EE627BF.8030001@livinglogic.de>

Steven Taschuk wrote:

> [...]
> I would also like the traceback to be an attribute of the
> exception object (circular references be damned!), specified by
> optional keyword argument to Exception.__init__.  This would
> require that people writing their own exception classes be sure to
> extend, not override, Exception.__init__.

Wouldn't it make more sense to associate the traceback with the
exception instance when the exception is raised, not when the
exception is instantiated? As long as the exception isn't raised
it's just a normal object without a traceback attached.

The warning framework and PEP 293 use unraised exceptions for passing
around error information, it would be bad if the would gain traceback
info automatically.

Bye,
    Walter Dörwald




From walter@livinglogic.de  Tue Jun 10 20:09:44 2003
From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Tue, 10 Jun 2003 21:09:44 +0200
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <3EE4EB57.2090803@ocf.berkeley.edu>
References: <200306090621.h596LgF24277@oma.cosc.canterbury.ac.nz> <3EE4E2F6.2050403@ocf.berkeley.edu> <3EE4EB57.2090803@ocf.berkeley.edu>
Message-ID: <3EE62CF8.5040406@livinglogic.de>

Brett C. wrote:
> Brett C. wrote:
> 
>> Greg Ewing wrote:
>>
>>>> can we now consider implementing chained exceptions as has been 
>>>> mentioned here numerous times?
>>>
>>>
>>>
>>>
>>> I must have missed that. What are chained exceptions?
>>>
> <SNIP>
> 
>> This was discussed on the list between Ping and I think Walter (could 
>> be wrong about Walter but I know Ping was involved).  Should be in the 
>> Summary archive somewhere; just need to find it.  =)
>>
> 
> Found it.
> 
> Raymond apparently instigated the thread: 
> http://mail.python.org/pipermail/python-dev/2003-January/032492.html
> 
> And it continued into the next month: 
> http://mail.python.org/pipermail/python-dev/2003-February/032864.html
> 
> And you even contributed to the discussion, Greg =) :
> http://mail.python.org/pipermail/python-dev/2003-January/032513.html
> 
> But the original terminology was "exception masking" so that may have 
> been why this didn't ring any bells.
> 
> For the impatient you can read the last 3 emails I think (especially the 
> absolute last which was authored by Raymond) to get a summary of the 
> ideas proposed.

An open question for exception chaining was which exception type is
tested in the except statement, the innermost or the outermost one.

I'd say for backwards compatibility reasons this should be the outermost
exception, but we could add a new feature to that: Add a new exception
subclass named Info that can be used to wrap exceptions without
influencing the type of the exception raised. This could be used
by code higher up in the call chain to add information to the
exception without changing the type that gets caught in the except
statement. For example filter() could be changed to add information
about the iteration index where the exception happened:

class spam:
    def __getitem__(self, index):
       if index==42:
          raise TypeError
       return None

x = filter(None, spam())

this might give:

Traceback (most recent call last):
   File "spam.py", line 8, in ?
     x = filter(None, foo())
   File "spam.py", line 4, in __getitem__
     raise TypeError("ouch")
TypeError: ouch
Info: in filter() at index 42

Bye,
    Walter Dörwald



From drifty@alum.berkeley.edu  Tue Jun 10 21:36:06 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Tue, 10 Jun 2003 13:36:06 -0700
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <3EE62CF8.5040406@livinglogic.de>
References: <200306090621.h596LgF24277@oma.cosc.canterbury.ac.nz> <3EE4E2F6.2050403@ocf.berkeley.edu> <3EE4EB57.2090803@ocf.berkeley.edu> <3EE62CF8.5040406@livinglogic.de>
Message-ID: <3EE64136.6070001@ocf.berkeley.edu>

Walter D=F6rwald wrote:
>=20
> An open question for exception chaining was which exception type is
> tested in the except statement, the innermost or the outermost one.
>=20
> I'd say for backwards compatibility reasons this should be the outermos=
t
> exception,

That's what I was thinking.  Simpler and no surprises for old code.

> but we could add a new feature to that: Add a new exception
> subclass named Info that can be used to wrap exceptions without
> influencing the type of the exception raised. This could be used
> by code higher up in the call chain to add information to the
> exception without changing the type that gets caught in the except
> statement. For example filter() could be changed to add information
> about the iteration index where the exception happened:
>=20
> class spam:
>    def __getitem__(self, index):
>       if index=3D=3D42:
>          raise TypeError
>       return None
>=20
> x =3D filter(None, spam())
>=20
> this might give:
>=20
> Traceback (most recent call last):
>   File "spam.py", line 8, in ?
>     x =3D filter(None, foo())
>   File "spam.py", line 4, in __getitem__
>     raise TypeError("ouch")
> TypeError: ouch
> Info: in filter() at index 42
>=20

So have a function that takes the current exception, stores it as an=20
attribute of a new one, and have exception-handling code no of the=20
possible existence of the attribute and print out the info if it exists?

-Brett



From staschuk@telusplanet.net  Tue Jun 10 23:06:48 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Tue, 10 Jun 2003 16:06:48 -0600
Subject: [Python-Dev] PEP-317
In-Reply-To: <200306101559.h5AFx6d19747@odiug.zope.com>; from guido@python.org on Tue, Jun 10, 2003 at 11:59:06AM -0400
References: <200306092312.h59NCDK05605@oma.cosc.canterbury.ac.nz> <200306100023.h5A0NdX15842@pcp02138704pcs.reston01.va.comcast.net> <20030610091011.B374@tibia.amotlpaa.bogus> <200306101559.h5AFx6d19747@odiug.zope.com>
Message-ID: <20030610160648.B1111@tibia.amotlpaa.bogus>

Quoth Guido van Rossum:
  [...]
> I've never considered the two alternative raise syntaxes as a wart in
> the language that's important enough to fix.  The predicted migration
> pain seems excessive compared to the importance of the improvement.

Gotcha.

And, in case there's any doubt, I certainly agree that such an
objection is more than adequate reason to reject a PEP, and that I
haven't adequately met the objection (yet... he said hopefully).

> The only case I'm willing to impose excessive migration pain to fix a
> problem is when the problem is *really* unacceptable in the long run.
> I've decided that's the case for int division, for the difference
> between int and long, and for new-style vs. classic classes.
> 
> I don't see raise C vs. raise C() to be in the same category.

I entirely agree that it isn't.

-- 
Steven Taschuk                  staschuk@telusplanet.net
"Telekinesis would be worth patenting."  -- James Gleick


From staschuk@telusplanet.net  Wed Jun 11 00:26:10 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Tue, 10 Jun 2003 17:26:10 -0600
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <20030610142302.GA26466@panix.com>; from aahz@pythoncraft.com on Tue, Jun 10, 2003 at 10:23:02AM -0400
References: <1055253130.3ee5e28ab7650@mcherm.com> <200306101411.h5AEBWg13102@odiug.zope.com> <20030610142302.GA26466@panix.com>
Message-ID: <20030610172610.C2153@tibia.amotlpaa.bogus>

Quoth Aahz:
  [...]
>                 raise Found()
> except Found:
  [...]
> I find that extra set of parentheses unnecessary and ugly.  It implies a
> callable where it's not really being used that way, [...]

In
    raise Found
Found *is* being used as a callable under the hood; an instance of
Found is created implicitly.  You just happen not to care about
that instance.

> [...] particularly in the
> asymmetry between the ``raise`` and the ``except``.  [...]

'raise' and 'except' *are* asymmetrical; instances are raised, but
they are caught by class.  As the PEP says, the current syntactic
symmetry is misleading in general (though, I admit, not especially
so in your code sample).

> [...] If this change goes
> through, I might start doing
> 
> class Found(Exception):
>     pass
> Found = Found()

That you think this would work supports my claim that the present
syntax is misleading.  <wink>

-- 
Steven Taschuk                            staschuk@telusplanet.net
Every public frenzy produces legislation purporting to address it.
                                                  (Kinsley's Law)


From staschuk@telusplanet.net  Tue Jun 10 23:07:10 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Tue, 10 Jun 2003 16:07:10 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <3EE627BF.8030001@livinglogic.de>; from walter@livinglogic.de on Tue, Jun 10, 2003 at 08:47:27PM +0200
References: <20030609145131.GA20606@epoch.metaslash.com> <200306092235.h59MZFQ05461@oma.cosc.canterbury.ac.nz> <20030609174558.B2982@tibia.amotlpaa.bogus> <3EE627BF.8030001@livinglogic.de>
Message-ID: <20030610160710.C1111@tibia.amotlpaa.bogus>

Quoth Walter Dörwald:
> Steven Taschuk wrote:
> > [...]
> > I would also like the traceback to be an attribute of the
> > exception object (circular references be damned!), specified by
> > optional keyword argument to Exception.__init__.  [...]
> 
> Wouldn't it make more sense to associate the traceback with the
> exception instance when the exception is raised, not when the
> exception is instantiated? As long as the exception isn't raised
> it's just a normal object without a traceback attached.

Absolutely; my notion to use __init__ above actually makes no
sense, I subsequently realized.  Consider it withdrawn.

-- 
Steven Taschuk                                                 o- @
staschuk@telusplanet.net                                      7O   )
                                                               "  (


From staschuk@telusplanet.net  Wed Jun 11 00:16:35 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Tue, 10 Jun 2003 17:16:35 -0600
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <1055253130.3ee5e28ab7650@mcherm.com>; from mcherm@mcherm.com on Tue, Jun 10, 2003 at 06:52:10AM -0700
References: <1055253130.3ee5e28ab7650@mcherm.com>
Message-ID: <20030610171635.B2153@tibia.amotlpaa.bogus>

Quoth Michael Chermside:
> [...] Moving the traceback into
> the object is one idea. Making Exception a new-style object is another
> (no need to rush, but it'll happen SOMEDAY, right?). Exception
> chaining (aka exception masking) is another.
> 
> The point is, without PEP 317, you can't do these things, because sometimes
> you use an object, and sometimes just mention a class (and sometimes just
> use a string). [...]

Afaik this is not the case.  Eliminating string exceptions *is*
necessary for some of these ideas, but that's going to happen
anyway.  (I had to propose getting rid of string exceptions
explicitly just because it wasn't PEPped anywhere else.)  The real
point of PEP 317 is getting rid of implicit instantiation.

But implicit instantiation might not be an obstacle to the above.
As long as the exception object does get instantiated at or before
raise-time -- whether this occurs implicitly or explicitly --
tracebacks or pending exceptions or whatever can be assigned to it
as attributes.  (For the question of new-style exceptions, see my
reply to Guido of a few minutes ago.)

*Deferred* instantiation would be a more serious obstacle (since,
e.g., sometimes there would be no object to receive the traceback
attribute), but I don't think that's actually on the table.

  [...]
-- 
Steven Taschuk                                     staschuk@telusplanet.net
Receive them ignorant; dispatch them confused.  (Weschler's Teaching Motto)


From staschuk@telusplanet.net  Wed Jun 11 00:16:27 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Tue, 10 Jun 2003 17:16:27 -0600
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <200306101411.h5AEBWg13102@odiug.zope.com>; from guido@python.org on Tue, Jun 10, 2003 at 10:11:32AM -0400
References: <1055253130.3ee5e28ab7650@mcherm.com> <200306101411.h5AEBWg13102@odiug.zope.com>
Message-ID: <20030610171627.A2153@tibia.amotlpaa.bogus>

Quoth Guido van Rossum:
  [...]
> There seem to be lots of different things in that PEP (I've got no
> time to read it in full).

Not so many, actually.  Here's the extreme summary:

    Implicit instantiation sucks.  Here's how to get rid of it.  Oh,
    and I can't be bothered to work out how to keep string exceptions
    when this change is made, so let's get rid of them too.  Let's do
    this in 3.0 and put warnings in 2.4.

Btw, I quote you as being in favour of explicit instantiation.
(Though not, I should note, as being in favour of eliminating
implicit instantiation.)

> - making all exceptions derive from Exception: most probably
> - making Exception a new-style class: eventually

Neither of these is in the PEP, though as it happens I do support
both (pending migration plans, naturally).  Afaik, these are
orthogonal to eliminating implicit instantiation, except possibly
for one respect, discussed below.

  [implicit instantiation itself]
> I don't see how this change is necessary in order to get any of the
> other benefits.

Afaik the only possibility there is that implicit instantiation
might be an obstacle to new-style exceptions.  But equally it
might not be.

Details:

Early in the c.l.py discussions which provoked this PEP, it was
suggested that 'raise' would not be able to distinguish new-style
instances from new-style classes, and so would not be able to
decide reliably whether to instantiate implicitly.  If this were
true, implicit instantiation would have to be eliminated in order
to allow new-style exceptions in the future.

However, there seem to be at least two alternative solutions for
this problem:

    1. Make inheritance from Exception mandatory, and test
        if issubclass(firstarg, Exception): treat like class
        elif isinstance(firstarg, Exception): treat like instance
        else: blow up
    (There are also other reasons for wanting mandatory inheritance
    from Exception, but they don't relate to implicit instantiation in
    any way.)

    2. Test
        if isinstance(firstarg, type): treat like class
        else: treat like instance
    (This assumes string exceptions are long gone.)

Eliminating implicit instantiation definitely does away with the
problem entirely; it may be that one or both of the above
alternatives would suffice as well, though that is less clear to
me.  (Opinions solicited!)

> I also don't understand the commotion over deferred exception
> instantiation, since it doesn't happen except for exceptions
> raised from C code.

Apparently Pyrex uses the Python syntax for the C semantics.
Eliminating the implicit instantiation syntax from Python would
make Pyrex weirder for Python programmers.  (I do wonder whether
that would be a good thing, given that the semantics are actually
different.)

Afaik that's the only concern related to deferred instantiation.

-- 
Steven Taschuk                staschuk@telusplanet.net
"I tried to be pleasant and accommodating, but my head
 began to hurt from his banality."   -- _Seven_ (1996)


From drifty@alum.berkeley.edu  Wed Jun 11 00:52:23 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Tue, 10 Jun 2003 16:52:23 -0700
Subject: [Python-Dev] Sneaky 'super' instances
Message-ID: <3EE66F37.3040700@ocf.berkeley.edu>

Bug 729103 discovered an interesting little issue; 'super' instances 
cause inspect.isroutine to return True since it also poses as a non-data 
descriptor.  Now this is bad because pydoc then tries to get a __name__ 
attribute out of it which it lacks because it is an instance of a class 
and not really a function or method.

So, should I change inspect.isroutine to check to see if its argument is 
an instance of 'super'?  Is there a robust way to check if something is 
an instance of a class which could be used instead to make this more 
general (like lacking a __name__ attribute)?  Or do we just cause pydoc 
to spit out "RTM online" every time it raises an error.  =)

-Brett



From guido@python.org  Wed Jun 11 01:30:26 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 10 Jun 2003 20:30:26 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: "Your message of Tue, 10 Jun 2003 16:52:23 PDT."
 <3EE66F37.3040700@ocf.berkeley.edu>
References: <3EE66F37.3040700@ocf.berkeley.edu>
Message-ID: <200306110030.h5B0UQA17243@pcp02138704pcs.reston01.va.comcast.net>

> Bug 729103 discovered an interesting little issue; 'super' instances 
> cause inspect.isroutine to return True since it also poses as a non-data 
> descriptor.  Now this is bad because pydoc then tries to get a __name__ 
> attribute out of it which it lacks because it is an instance of a class 
> and not really a function or method.
> 
> So, should I change inspect.isroutine to check to see if its argument is 
> an instance of 'super'?  Is there a robust way to check if something is 
> an instance of a class which could be used instead to make this more 
> general (like lacking a __name__ attribute)?  Or do we just cause pydoc 
> to spit out "RTM online" every time it raises an error.  =)

inspect shouldn't assume hat just because isroutine() returns true,
there has to be a __name__ attribue.  Unfortunately, inspect is full
of such assumptions. :-)

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


From pje@telecommunity.com  Wed Jun 11 01:24:11 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Tue, 10 Jun 2003 20:24:11 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <3EE66F37.3040700@ocf.berkeley.edu>
Message-ID: <5.1.1.6.0.20030610200503.02108080@telecommunity.com>

At 04:52 PM 6/10/03 -0700, Brett C. wrote:
>Bug 729103 discovered an interesting little issue; 'super' instances cause 
>inspect.isroutine to return True since it also poses as a non-data 
>descriptor.  Now this is bad because pydoc then tries to get a __name__ 
>attribute out of it which it lacks because it is an instance of a class 
>and not really a function or method.
>
>So, should I change inspect.isroutine to check to see if its argument is 
>an instance of 'super'?  Is there a robust way to check if something is an 
>instance of a class which could be used instead to make this more general 
>(like lacking a __name__ attribute)?  Or do we just cause pydoc to spit 
>out "RTM online" every time it raises an error.  =)

IMO, inspect and pydoc are hopelessly broken in the post-2.2 world, in that 
they are built on pre-unification assumptions.  This example is just the 
tip of a very nasty iceberg.

I realize I'm not answering your question; I'm just taking the opportunity 
to bring back up something that Guido and I briefly discussed a couple 
months ago:

http://peak.telecommunity.com/protocol_ref/protocols-example1.html

If we had a framework such as the one described, and we realized we wanted 
super instances documented, we'd only need to decide how we'd like them to 
be documented, instead of trying to figure out what tangled web of 
assumptions pydoc and inspect (or other tools, for that matter) make about 
various kinds of objects.

I hope to have some cycles soon to work on such a framework, but since it 
effectively depends on both PEP 246 and an unwritten PEP for a "protocol 
declaration API" like the one in PyProtocols, it would be good to get some 
idea of whether the Python developer community feels this is a good 
direction for me to pursue.  In particular, it would be useful to have some 
feedback on whether PyProtocols looks PEP-worthy (for 2.4 stdlib, I 
presume).  If so, then it's also reasonable for me to target a 
documentation framework for that timeframe.  (Specifically, a set of 
interface definitions and adapters for Python built-ins, with a few simple 
output tools.)



From kbk@shore.net  Wed Jun 11 03:43:59 2003
From: kbk@shore.net (Kurt B. Kaiser)
Date: Tue, 10 Jun 2003 22:43:59 -0400
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: <m3isrjyait.fsf@mira.informatik.hu-berlin.de> (martin@v.loewis.de's
 message of "06 Jun 2003 08:39:54 +0200")
References: <m31xy85hec.fsf@float.attbi.com>
 <m3isrjyait.fsf@mira.informatik.hu-berlin.de>
Message-ID: <m3vfvdl4eo.fsf@float.attbi.com>

martin@v.loewis.de (Martin v. L=F6wis) writes:

> kbk@shore.net (Kurt B. Kaiser) writes:
>
>> 8. Tweak .../Tools/idle/setup.py to install at
>>    .../site-packages/old_idlelib (with the bin script named similarly)
>>    so if someone /did/ do an install there would not be a conflict.
>>    Maybe this should be done first?
>
> What is the purpose of Tools/idle? Shouldn't it be deleted altogether?

I would think so, but maybe not until the new IDLE is working.  I'd
assume it would be deleted before 2.3 final.=20=20

I don't feel strongly about this.  I had suggested to Guido that it
be renamed old_idle for now to avoid conflict, and he seemed to be
fine with that.

If no one has objections, I'll check in a change to Tools/idle to
modify setup.py to install it as above, with a script named
'old_idle'.

I don't know what affect this has on the Windows build procedure.
__
KBK


From python@rcn.com  Wed Jun 11 04:59:59 2003
From: python@rcn.com (Raymond Hettinger)
Date: Tue, 10 Jun 2003 23:59:59 -0400
Subject: [Python-Dev] Sneaky 'super' instances
References: <3EE66F37.3040700@ocf.berkeley.edu> <200306110030.h5B0UQA17243@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <000001c32fd0$978b55e0$9b07a044@oemcomputer>

> > Bug 729103 discovered an interesting little issue; 'super' instances 
> > cause inspect.isroutine to return True since it also poses as a non-data 
> > descriptor.  Now this is bad because pydoc then tries to get a __name__ 
> > attribute out of it which it lacks because it is an instance of a class 
> > and not really a function or method.
> > 
> > So, should I change inspect.isroutine to check to see if its argument is 
> > an instance of 'super'?  

That is a reasonable short-term solution but it should go 
one layer down in ismethoddescriptor().  Append the line:

    and not isinstance(object, super)


Raymond Hettinger


From martin@v.loewis.de  Wed Jun 11 06:14:17 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 11 Jun 2003 07:14:17 +0200
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <5.1.1.6.0.20030610200503.02108080@telecommunity.com>
References: <5.1.1.6.0.20030610200503.02108080@telecommunity.com>
Message-ID: <m3adcp9owm.fsf@mira.informatik.hu-berlin.de>

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

> I hope to have some cycles soon to work on such a framework, but since
> it effectively depends on both PEP 246 and an unwritten PEP for a
> "protocol declaration API" like the one in PyProtocols, it would be
> good to get some idea of whether the Python developer community feels
> this is a good direction for me to pursue.

I'm quite skeptical about "grand new architectures" whose development
starts off with "what we have is rubbish". In my experience, the
rubbish that we have right now continues to be much better than what
the grand new architecture can deliver for several years to come. So I
would always favour evolution over revolution.

That said: Feel free to attempt a revolution, but I can only be
convinced that it is good when I see how actual code gives me actual
pydoc-style pages in my web browser.

Regards,
Martin


From guido@python.org  Wed Jun 11 06:35:38 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 01:35:38 -0400
Subject: [Python-Dev] IDLEfork Re-integration into Python
In-Reply-To: "Your message of Tue, 10 Jun 2003 22:43:59 EDT."
 <m3vfvdl4eo.fsf@float.attbi.com>
References: <m31xy85hec.fsf@float.attbi.com>
 <m3isrjyait.fsf@mira.informatik.hu-berlin.de> <m3vfvdl4eo.fsf@float.attbi.com>
Message-ID: <200306110535.h5B5ZcL17604@pcp02138704pcs.reston01.va.comcast.net>

> > What is the purpose of Tools/idle? Shouldn't it be deleted altogether?
> 
> I would think so, but maybe not until the new IDLE is working.  I'd
> assume it would be deleted before 2.3 final.  

Right -- in fact, it can be deleted as soon as we know the new idle
works.

> I don't feel strongly about this.  I had suggested to Guido that it
> be renamed old_idle for now to avoid conflict, and he seemed to be
> fine with that.

Hm, I think that's unnecessarily conservative.  We can leave it
untouched for a while and delete it before beta 2.

> If no one has objections, I'll check in a change to Tools/idle to
> modify setup.py to install it as above, with a script named
> 'old_idle'.

Not needed.

> I don't know what affect this has on the Windows build procedure.

We'll find out.

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


From guido@python.org  Wed Jun 11 07:12:32 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 02:12:32 -0400
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: "Your message of Tue, 10 Jun 2003 17:16:27 MDT."
 <20030610171627.A2153@tibia.amotlpaa.bogus>
References: <1055253130.3ee5e28ab7650@mcherm.com>
 <200306101411.h5AEBWg13102@odiug.zope.com>
 <20030610171627.A2153@tibia.amotlpaa.bogus>
Message-ID: <200306110612.h5B6CW117710@pcp02138704pcs.reston01.va.comcast.net>

> Guido van Rossum:
>   [...]
> > There seem to be lots of different things in that PEP (I've got no
> > time to read it in full).

[Steven T]
> Not so many, actually.  Here's the extreme summary:
> 
>     Implicit instantiation sucks.  Here's how to get rid of it.  Oh,
>     and I can't be bothered to work out how to keep string exceptions
>     when this change is made, so let's get rid of them too.  Let's do
>     this in 3.0 and put warnings in 2.4.

I've now read the PEP, and it simply fails to explain why implicit
instantiation sucks so badly as to require all this pain.  The
arguments of readability and consistency are pretty mild suckage IMO.

[...]
> Afaik the only possibility there is that implicit instantiation
> might be an obstacle to new-style exceptions.  But equally it
> might not be.

It would be simple enough to introduce new-style exceptions if
Exception were made a new-style class and at the same time all
new-style exceptions were required to derive from Exception:

  raise x

would check whether x was:

  - a string (but not an instance of a true subclass of str)
  - a classic class
  - an instance of a classic class
  - Exception or a subclass thereof
  - an instance of Exception or of a subclass thereof

Where the first three cases are for backward compatibility.

Similarly, the rule for

  raise x, y

should allows x to be

  - a string
  - a classic class
  - Exception or a subclass thereof

and in the last two cases, y could either be an instance of x (or of a
subclass of x!), or an argument for x, or a tuple of arguments for x.

> Details:
> 
> Early in the c.l.py discussions which provoked this PEP, it was
> suggested that 'raise' would not be able to distinguish new-style
> instances from new-style classes, and so would not be able to
> decide reliably whether to instantiate implicitly.  If this were
> true, implicit instantiation would have to be eliminated in order
> to allow new-style exceptions in the future.
> 
> However, there seem to be at least two alternative solutions for
> this problem:
> 
>     1. Make inheritance from Exception mandatory, and test
>         if issubclass(firstarg, Exception): treat like class
>         elif isinstance(firstarg, Exception): treat like instance
>         else: blow up
>     (There are also other reasons for wanting mandatory inheritance
>     from Exception, but they don't relate to implicit instantiation in
>     any way.)
> 
>     2. Test
>         if isinstance(firstarg, type): treat like class
>         else: treat like instance
>     (This assumes string exceptions are long gone.)

Right.  Either is better than the draconian solution from PEP 317.

> Eliminating implicit instantiation definitely does away with the
> problem entirely; it may be that one or both of the above
> alternatives would suffice as well, though that is less clear to
> me.  (Opinions solicited!)

ATM I'm inclined to require deriving from Exception, allowing classic
classes (and even strings) for backwards compatibility as stated above.

> > I also don't understand the commotion over deferred exception
> > instantiation, since it doesn't happen except for exceptions
> > raised from C code.
> 
> Apparently Pyrex uses the Python syntax for the C semantics.

Well, Pyrex is its own language, even though it resembles Python.

> Eliminating the implicit instantiation syntax from Python would
> make Pyrex weirder for Python programmers.  (I do wonder whether
> that would be a good thing, given that the semantics are actually
> different.)

Pyrex is weird enough already; this quirk wouldn't be hard to document
and has to be documented anyway.

> Afaik that's the only concern related to deferred instantiation.

Not quite. :-)

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


From Raymond Hettinger" <python@rcn.com  Wed Jun 11 09:24:28 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Wed, 11 Jun 2003 04:24:28 -0400
Subject: [Python-Dev] Updated 2.3 Release Schedule
Message-ID: <002b01c32ff2$e0b5ae60$59b92c81@oemcomputer>

Once IDLEFORK is merged, is it time for a second Py2.3 beta release?
Also, is July still reasonable for Py2.3 final?


Raymond Hettinger


From mal@lemburg.com  Wed Jun 11 09:36:06 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 11 Jun 2003 10:36:06 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135
In-Reply-To: <E19Q0mC-0005Le-00@sc8-pr-cvs1.sourceforge.net>
References: <E19Q0mC-0005Le-00@sc8-pr-cvs1.sourceforge.net>
Message-ID: <3EE6E9F6.80902@lemburg.com>

rhettinger@users.sourceforge.net wrote:
> Update of /cvsroot/python/python/dist/src/Doc/lib
> In directory sc8-pr-cvs1:/tmp/cvs-serv19944
> 
> Modified Files:
> 	libfuncs.tex 
> Log Message:
> SF bug #660022: parameters for int(), str(), etc.
> 
> * Indicate that arguments are optional for most builtin type constructors.
 > ...
> ! \begin{funcdesc}{bool}{\optional{x}}

This sounds weird:

* Why should object constructors have an optional argument without
   a default value ? Why aren't these default values documented ?

* This "feature" sounds like it will hide programming errors.

* What is the purpose of the "feature" ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 11 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        13 days left



From Paul.Moore@atosorigin.com  Wed Jun 11 09:44:49 2003
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Wed, 11 Jun 2003 09:44:49 +0100
Subject: [Python-Dev] Sneaky 'super' instances
Message-ID: <16E1010E4581B049ABC51D4975CEDB88619A95@UKDCX001.uk.int.atosorigin.com>

From: Martin v. L=F6wis [mailto:martin@v.loewis.de]
> "Phillip J. Eby" <pje@telecommunity.com> writes:

>> I hope to have some cycles soon to work on such a framework, but =
since
>> it effectively depends on both PEP 246 and an unwritten PEP for a
>> "protocol declaration API" like the one in PyProtocols, it would be
>> good to get some idea of whether the Python developer community feels
>> this is a good direction for me to pursue.

> I'm quite skeptical about "grand new architectures" whose development
> starts off with "what we have is rubbish". In my experience, the
> rubbish that we have right now continues to be much better than what
> the grand new architecture can deliver for several years to come. So I
> would always favour evolution over revolution.

To some extent I agree with this. I haven't taken the time to *fully*
digest the adaptation PEP or Phillip's protocol ideas, but my general
impression is that they hover somewhere on the border. Their proponents
describe them as if they were grand new architectures, with an
implication of "let's rewrite everything" because "what we have is
rubbish" (as you say).

But in practice, I can't see anything in either of these proposals which
really needs much change to what we currently have. I suspect that the
reality is that they are more or less descriptions of "useful patterns"
which can be used to offer a standard answer to issues which sometimes
come up with current methods, but which aren't frequent or severe enough
to justify major angst. (For example, the old one about what precisely
constitutes a "file-like" object in a given context). In this context,
it's not entirely clear to me why the proposals need "official =
sanction",
as opposed to simply being made available as user-level libraries, with
the possibility of migrating to "standard" status if the level of =
interest
proves to justify it.

As usual, I suspect the reality is somewhere between these two extremes.
But I'd like to see the two proposals restated in the form of working
library code. Then I could *try* them rather than arguing about theory.
[Of course if there really *is* a need for language support, this would
focus on the *exact* language change needed, along with a real use case
to justify it.]

Paul.


From python@rcn.com  Wed Jun 11 09:47:06 2003
From: python@rcn.com (Raymond Hettinger)
Date: Wed, 11 Jun 2003 04:47:06 -0400
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135
References: <E19Q0mC-0005Le-00@sc8-pr-cvs1.sourceforge.net> <3EE6E9F6.80902@lemburg.com>
Message-ID: <003d01c32ff6$2dad53a0$59b92c81@oemcomputer>

> > * Indicate that arguments are optional for most builtin type constructors.
>  > ...
> > ! \begin{funcdesc}{bool}{\optional{x}}
> 
> This sounds weird:
> 
> * Why should object constructors have an optional argument without
>    a default value ? Why aren't these default values documented ?
> 
> * This "feature" sounds like it will hide programming errors.
> 
> * What is the purpose of the "feature" ?

I'm not following whether you don't like the implementation or 
documentation.  My patch just documents the existing implementation.

The implementation has been in for a while (GvR checked in Alex's 
patch for www.python.org/sf/724135 ).  The news item reads:

- bool() called without arguments now returns False rather than
  raising an exception.  This is consistent with calling the
  constructors for the other builtin types -- called without argument
  they all return the false value of that type.  (SF patch #724135)


Raymond Hettinger


From python@rcn.com  Wed Jun 11 09:55:04 2003
From: python@rcn.com (Raymond Hettinger)
Date: Wed, 11 Jun 2003 04:55:04 -0400
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135
References: <E19Q0mC-0005Le-00@sc8-pr-cvs1.sourceforge.net> <3EE6E9F6.80902@lemburg.com>
Message-ID: <000901c32ff7$2703e4a0$993cc797@oemcomputer>

If it helps, here is the text on the subject from GvR's tutorial on new style classes:

"""I've made sure that the types can be called with exactly the same argument lists as the former functions. (They can also
generally be called without arguments, producing an object with a suitable default value, such as zero or empty; this is new.) """


Raymond


#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################


From mal@lemburg.com  Wed Jun 11 10:00:27 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 11 Jun 2003 11:00:27 +0200
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins] python/dist/src/Doc/lib
 libfuncs.tex,1.134,1.135)
In-Reply-To: <003d01c32ff6$2dad53a0$59b92c81@oemcomputer>
References: <E19Q0mC-0005Le-00@sc8-pr-cvs1.sourceforge.net>	<3EE6E9F6.80902@lemburg.com> <003d01c32ff6$2dad53a0$59b92c81@oemcomputer>
Message-ID: <3EE6EFAB.5070301@lemburg.com>

Raymond Hettinger wrote:
>>>* Indicate that arguments are optional for most builtin type constructors.
>>
>> > ...
>>
>>>! \begin{funcdesc}{bool}{\optional{x}}
>>
>>This sounds weird:
>>
>>* Why should object constructors have an optional argument without
>>   a default value ? Why aren't these default values documented ?
>>
>>* This "feature" sounds like it will hide programming errors.
>>
>>* What is the purpose of the "feature" ?
> 
> I'm not following whether you don't like the implementation or 
> documentation.  My patch just documents the existing implementation.

Your patch just made me aware of this fact (whether or not it's
a good feature, having accurate documentation is always good :-).

> The implementation has been in for a while (GvR checked in Alex's 
> patch for www.python.org/sf/724135 ).  The news item reads:
> 
> - bool() called without arguments now returns False rather than
>   raising an exception.  This is consistent with calling the
>   constructors for the other builtin types -- called without argument
>   they all return the false value of that type.  (SF patch #724135)

I seriously question the usefulness of such an approach. It
doesn't seem to buy us anything and is likely to hide typos
or progamming errors.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 11 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        13 days left



From mwh@python.net  Wed Jun 11 11:34:28 2003
From: mwh@python.net (Michael Hudson)
Date: Wed, 11 Jun 2003 11:34:28 +0100
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <20030610172610.C2153@tibia.amotlpaa.bogus> (Steven Taschuk's
 message of "Tue, 10 Jun 2003 17:26:10 -0600")
References: <1055253130.3ee5e28ab7650@mcherm.com>
 <200306101411.h5AEBWg13102@odiug.zope.com>
 <20030610142302.GA26466@panix.com>
 <20030610172610.C2153@tibia.amotlpaa.bogus>
Message-ID: <2misrcgax7.fsf@starship.python.net>

Steven Taschuk <staschuk@telusplanet.net> writes:

> That you think this would work supports my claim that the present
> syntax is misleading.  <wink>

While we're at weird exception stuff... while aping bits of the
exception handling code for pypy, I noticed that this should "work",
and indeed it does:

>>> raise ((((Exception,), 'anything'), 'can', 'go'), 'in here'), 'arg'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Exception: arg

Any takers for an explanation?

Cheers,
M.

-- 
  ARTHUR:  The ravenous bugblatter beast of Traal ... is it safe?
    FORD:  Oh yes, it's perfectly safe ... it's just us who are in 
           trouble.
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 6


From mcherm@mcherm.com  Wed Jun 11 12:27:25 2003
From: mcherm@mcherm.com (Michael Chermside)
Date: Wed, 11 Jun 2003 04:27:25 -0700
Subject: [Python-Dev] RE: PEP-317
Message-ID: <1055330845.3ee7121d0c36c@mcherm.com>

Guido writes:
> It would be simple enough to introduce new-style exceptions if
> Exception were made a new-style class and at the same time all
> new-style exceptions were required to derive from Exception:
> 
>   raise x
> 
> would check whether x was:
> 
>   - a string (but not an instance of a true subclass of str)
>   - a classic class
>   - an instance of a classic class
>   - Exception or a subclass thereof
>   - an instance of Exception or of a subclass thereof
> 
> Where the first three cases are for backward compatibility.
> 
> Similarly, the rule for
> 
>   raise x, y
> 
> should allows x to be
> 
>   - a string
>   - a classic class
>   - Exception or a subclass thereof
> 
> and in the last two cases, y could either be an instance of x (or of a
> subclass of x!), or an argument for x, or a tuple of arguments for x.

Okay, after hearing this (plus all the arguments about PEP 317
requiring an excessive level of migration pain), I am now convinced.

If the PEP winds up being officially rejected, I propose that it
grow a "rejection reasons" section explaing why, and that this section
also describe the above plan as the "plausible alternative" to PEP 317
for eventual migration to new-style exceptions.

-- Michael Chermside



From guido@python.org  Wed Jun 11 13:59:55 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 08:59:55 -0400
Subject: [Python-Dev] Updated 2.3 Release Schedule
In-Reply-To: "Your message of Wed, 11 Jun 2003 04:24:28 EDT."
 <002b01c32ff2$e0b5ae60$59b92c81@oemcomputer>
References: <002b01c32ff2$e0b5ae60$59b92c81@oemcomputer>
Message-ID: <200306111259.h5BCxuG20628@pcp02138704pcs.reston01.va.comcast.net>

> Once IDLEFORK is merged, is it time for a second Py2.3 beta release?

A few other things ought to be dealt with, but basically, yes.

> Also, is July still reasonable for Py2.3 final?

Hardly.  I've been held up, and don't expect to be able to work on
this much until after OSCON (July 7-11)...

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


From guido@python.org  Wed Jun 11 14:01:52 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 09:01:52 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: "Your message of Wed, 11 Jun 2003 09:44:49 BST."
 <16E1010E4581B049ABC51D4975CEDB88619A95@UKDCX001.uk.int.atosorigin.com>
References: <16E1010E4581B049ABC51D4975CEDB88619A95@UKDCX001.uk.int.atosorigin.com>
Message-ID: <200306111301.h5BD1q220645@pcp02138704pcs.reston01.va.comcast.net>

> > "Phillip J. Eby" <pje@telecommunity.com> writes:
>=20
> >> I hope to have some cycles soon to work on such a framework, but=
 since
> >> it effectively depends on both PEP 246 and an unwritten PEP for =
a
> >> "protocol declaration API" like the one in PyProtocols, it would=
 be
> >> good to get some idea of whether the Python developer community =
feels
> >> this is a good direction for me to pursue.
>=20
> From: Martin v. L=F6wis [mailto:martin@v.loewis.de]
> > I'm quite skeptical about "grand new architectures" whose develop=
ment
> > starts off with "what we have is rubbish". In my experience, the
> > rubbish that we have right now continues to be much better than w=
hat
> > the grand new architecture can deliver for several years to come.=
 So I
> > would always favour evolution over revolution.
>=20
[Paul Moore]
> To some extent I agree with this. I haven't taken the time to *full=
y*
> digest the adaptation PEP or Phillip's protocol ideas, but my gener=
al
> impression is that they hover somewhere on the border. Their propon=
ents
> describe them as if they were grand new architectures, with an
> implication of "let's rewrite everything" because "what we have is
> rubbish" (as you say).
>=20
> But in practice, I can't see anything in either of these proposals =
which
> really needs much change to what we currently have. I suspect that =
the
> reality is that they are more or less descriptions of "useful patte=
rns"
> which can be used to offer a standard answer to issues which someti=
mes
> come up with current methods, but which aren't frequent or severe e=
nough
> to justify major angst. (For example, the old one about what precis=
ely
> constitutes a "file-like" object in a given context). In this conte=
xt,
> it's not entirely clear to me why the proposals need "official sanc=
tion",
> as opposed to simply being made available as user-level libraries, =
with
> the possibility of migrating to "standard" status if the level of i=
nterest
> proves to justify it.
>=20
> As usual, I suspect the reality is somewhere between these two extr=
emes.
> But I'd like to see the two proposals restated in the form of worki=
ng
> library code. Then I could *try* them rather than arguing about the=
ory.
> [Of course if there really *is* a need for language support, this w=
ould
> focus on the *exact* language change needed, along with a real use =
case
> to justify it.]

Well said.

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



From guido@python.org  Wed Jun 11 14:05:08 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 09:05:08 -0400
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: "Your message of Wed, 11 Jun 2003 11:00:27 +0200."
 <3EE6EFAB.5070301@lemburg.com>
References: <E19Q0mC-0005Le-00@sc8-pr-cvs1.sourceforge.net>
 <3EE6E9F6.80902@lemburg.com> <003d01c32ff6$2dad53a0$59b92c81@oemcomputer>
 <3EE6EFAB.5070301@lemburg.com>
Message-ID: <200306111305.h5BD58U20664@pcp02138704pcs.reston01.va.comcast.net>

> > - bool() called without arguments now returns False rather than
> >   raising an exception.  This is consistent with calling the
> >   constructors for the other builtin types -- called without argument
> >   they all return the false value of that type.  (SF patch #724135)
> 
> I seriously question the usefulness of such an approach. It
> doesn't seem to buy us anything and is likely to hide typos
> or progamming errors.

Types with constructors that insist on an argument are problematic to
generic code that tries to instantiate a type by simply calling it.

I don't think that there's much chance that e.g. str() or int() will
be used by accident and not discovered right away.

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


From pje@telecommunity.com  Wed Jun 11 14:03:28 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Wed, 11 Jun 2003 09:03:28 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <m3adcp9owm.fsf@mira.informatik.hu-berlin.de>
References: <5.1.1.6.0.20030610200503.02108080@telecommunity.com>
 <5.1.1.6.0.20030610200503.02108080@telecommunity.com>
Message-ID: <5.1.0.14.0.20030611084923.041cce50@mail.telecommunity.com>

At 07:14 AM 6/11/03 +0200, Martin v. =?iso-8859-15?q?L=F6wis?= wrote:
>"Phillip J. Eby" <pje@telecommunity.com> writes:
>
> > I hope to have some cycles soon to work on such a framework, but since
> > it effectively depends on both PEP 246 and an unwritten PEP for a
> > "protocol declaration API" like the one in PyProtocols, it would be
> > good to get some idea of whether the Python developer community feels
> > this is a good direction for me to pursue.
>
>I'm quite skeptical about "grand new architectures" whose development
>starts off with "what we have is rubbish". In my experience, the
>rubbish that we have right now continues to be much better than what
>the grand new architecture can deliver for several years to come. So I
>would always favour evolution over revolution.
>
>That said: Feel free to attempt a revolution, but I can only be
>convinced that it is good when I see how actual code gives me actual
>pydoc-style pages in my web browser.

Fair enough.  I guess I should also clarify my "hopelessly broken" remark.

Since I work heavily with metaclasses, interfaces, and custom descriptors, 
pydoc doesn't work very well for me.  So I tend to use HappyDoc.  But 
HappyDoc doesn't handle nested classes.  (Actually, I'm not sure *any* 
current Python tool handles nested classes correctly.)  And so on.  I've 
yet to find a Python documentation tool that actually supports everything 
the language itself does.  On the scale of brokenness of the tool, 
however,  for my purposes pydoc is near the top of the list.  I've tried 
hacking on it a bit, but its assumptions run deep.  By comparison, other 
tools like epydoc required a lot less hacking to get them not to crash 
while inspecting straightforward post-2.2 constructs.  (Epydoc is also 
based on the inspect module.)  But Epydoc is more robust mainly because it 
punts by using 'repr()' when it can't figure something out.

Please note also that I wasn't trying to get anybody else to sign up to do 
the work.  I'm interested more in the availability of design feedback for 
the project; "customers", if you will.  If you're happy with pydoc and 
don't consider it broken for your purposes, then you logically and 
naturally would not be interested in improving or replacing it with 
something better.



From guido@python.org  Wed Jun 11 14:12:35 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 09:12:35 -0400
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: "Your message of Wed, 11 Jun 2003 11:34:28 BST."
 <2misrcgax7.fsf@starship.python.net>
References: <1055253130.3ee5e28ab7650@mcherm.com>
 <200306101411.h5AEBWg13102@odiug.zope.com> <20030610142302.GA26466@panix.com>
 <20030610172610.C2153@tibia.amotlpaa.bogus>
 <2misrcgax7.fsf@starship.python.net>
Message-ID: <200306111312.h5BDCZk20687@pcp02138704pcs.reston01.va.comcast.net>

> While we're at weird exception stuff... while aping bits of the
> exception handling code for pypy, I noticed that this should "work",
> and indeed it does:
> 
> >>> raise ((((Exception,), 'anything'), 'can', 'go'), 'in here'), 'arg'
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> Exception: arg
> 
> Any takers for an explanation?

When there were only string exceptions, I noticed the need for naming
a group of exceptions, e.g.

    io_related = (IOError, OSError, socket.SocketError)

    try:
	<some I/O intense stuff>
    except io_related, e:
	print "Some kind of I/O related error occurred:", e

So I implemented this.  Then (still back in the string exceptions
days) I realized that once something like that is named, it pretty
much behaves like a single exception, so I figured that it should be
possible to raise it as well.  This allows "upgrading" an exception
declared in a module to a group of exceptions without breaking code
that raises one of these.

I think the reasoning still holds, but:

(1) The syntax to catch multiple exceptions causes common mistakes
    like this:

    try:
        <some indexing operation>
    except KeyError, IndexError:
        <error handling>

(2) For upgrading exceptions, multiple inheritance makes more sense.

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


From guido@python.org  Wed Jun 11 14:13:29 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 09:13:29 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: "Your message of Wed, 11 Jun 2003 04:27:25 PDT."
 <1055330845.3ee7121d0c36c@mcherm.com>
References: <1055330845.3ee7121d0c36c@mcherm.com>
Message-ID: <200306111313.h5BDDTj20704@pcp02138704pcs.reston01.va.comcast.net>

> If the PEP winds up being officially rejected, I propose that it
> grow a "rejection reasons" section explaing why, and that this section
> also describe the above plan as the "plausible alternative" to PEP 317
> for eventual migration to new-style exceptions.

I strongly recommend doing that.  I hereby officially reject PEP 317.

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


From pje@telecommunity.com  Wed Jun 11 14:23:56 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Wed, 11 Jun 2003 09:23:56 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <16E1010E4581B049ABC51D4975CEDB88619A95@UKDCX001.uk.int.ato
 sorigin.com>
Message-ID: <5.1.0.14.0.20030611090605.02b46a00@mail.telecommunity.com>

At 09:44 AM 6/11/03 +0100, Moore, Paul wrote:

>But in practice, I can't see anything in either of these proposals which
>really needs much change to what we currently have. I suspect that the
>reality is that they are more or less descriptions of "useful patterns"
>which can be used to offer a standard answer to issues which sometimes
>come up with current methods, but which aren't frequent or severe enough
>to justify major angst. (For example, the old one about what precisely
>constitutes a "file-like" object in a given context). In this context,
>it's not entirely clear to me why the proposals need "official sanction",
>as opposed to simply being made available as user-level libraries, with
>the possibility of migrating to "standard" status if the level of interest
>proves to justify it.

PEP 246 has a chicken-and-egg problem, because it's only useful if it's 
being used.  adapt() by itself isn't at all useful if you don't have 
components or protocols that support it.  And nobody wants to write 
components or protocols to support it, if nobody is using adapt().  If I 
understand Alex and Clark's intentions in writing the PEP, it was to get 
adapt() to have a ubiquitous presence, so that authors could assume their 
users would be able to use it.

Two years after the original PEP, I saw a way to make use of it in a 
framework I was working on, and then noticed the chicken-and-egg 
problem.  But, one thing that had changed since then was that Twisted and 
Zope both had significant "interface" packages.  I saw a way to unite them, 
using PEP 246 as a mechanism, and how to make a toolkit that would allow 
developers to use adapt() in their own programs, without having to wait for 
anybody else to adopt adapt().  I'm hoping this will end the 
chicken-and-egg problem for PEP 246, as well as increase interoperability 
between frameworks.


>As usual, I suspect the reality is somewhere between these two extremes.
>But I'd like to see the two proposals restated in the form of working
>library code. Then I could *try* them rather than arguing about theory.
>[Of course if there really *is* a need for language support, this would
>focus on the *exact* language change needed, along with a real use case
>to justify it.]

There is no need for language-level support; it's just a library.  And, 
PyProtocols, my PEP 246 implementation and extension, is available for 
download now.  As for the documentation framework sketched in the reference 
manual, that's not written.  It will be, at some point, because I need it 
for my work.  But, I'm wondering whether I should write it *such that it 
could go in the standard library*.

See, I could probably write the documentation tool faster if I used PEAK, 
my application framework.  But that would make it unlikely to ever be 
usable for the Python standard library, because that would be like 
distributing Zope in the standard library.

In effect, my question is, "Should I expend the extra effort to develop the 
documentation tool in such a way that it could easily be distributed with 
the standard library?"  And, since the tool would have to depend on 
PyProtocols, this means that (in effect) PyProtocols would have to be 
accepted for the standard library.

So, what I want to know is:

* Do other people find pydoc inadequate?

* Does it seem likely that PyProtocols would be considered as an addition 
to the standard library (and by implication, used to document the 
interfaces of "standard" Python objects)?

* Is there anything specific that anybody would want in an overhauled 
pydoc, that I should know about?

Perhaps that clarifies my position and questions a bit better.



From walter@livinglogic.de  Wed Jun 11 15:05:40 2003
From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Wed, 11 Jun 2003 16:05:40 +0200
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <3EE64136.6070001@ocf.berkeley.edu>
References: <200306090621.h596LgF24277@oma.cosc.canterbury.ac.nz> <3EE4E2F6.2050403@ocf.berkeley.edu> <3EE4EB57.2090803@ocf.berkeley.edu> <3EE62CF8.5040406@livinglogic.de> <3EE64136.6070001@ocf.berkeley.edu>
Message-ID: <3EE73734.9020907@livinglogic.de>

Brett C. wrote:

> Walter Dörwald wrote:
> 
> [...]
>> but we could add a new feature to that: Add a new exception
>> subclass named Info that can be used to wrap exceptions without
>> influencing the type of the exception raised. This could be used
>> by code higher up in the call chain to add information to the
>> exception without changing the type that gets caught in the except
>> statement. For example filter() could be changed to add information
>> about the iteration index where the exception happened:
>>
>> class spam:
>>    def __getitem__(self, index):
>>       if index==42:
>>          raise TypeError
>>       return None
>>
>> x = filter(None, spam())
>>
>> this might give:
>>
>> Traceback (most recent call last):
>>   File "spam.py", line 8, in ?
>>     x = filter(None, foo())
>>   File "spam.py", line 4, in __getitem__
>>     raise TypeError("ouch")
>> TypeError: ouch
>> Info: in filter() at index 42
>>
> 
> So have a function that takes the current exception, stores it as an 
> attribute of a new one,

This could be done automatically, i.e. whenever you call
PyErr_SetString() etc. the currently active exception will be normalized
and put into a fourth global variable (exc_cause). In Python code
whenever a exception handler raises a new exception the exception
that is currently handled could be set as the cause for this
exception automatically by the raise statement.

> and have exception-handling code no of the 
> possible existence of the attribute and print out the info if it exists?

I'd say, the attribute should always be there, but should be initialized
to None in the Exception constructor (they same should probably be done
for the traceback attribute).

Bye,
    Walter Dörwald




From guido@python.org  Wed Jun 11 15:28:12 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 10:28:12 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: Your message of "Wed, 11 Jun 2003 09:03:28 EDT."
 <5.1.0.14.0.20030611084923.041cce50@mail.telecommunity.com>
References: <5.1.1.6.0.20030610200503.02108080@telecommunity.com> <5.1.1.6.0.20030610200503.02108080@telecommunity.com>
 <5.1.0.14.0.20030611084923.041cce50@mail.telecommunity.com>
Message-ID: <200306111428.h5BESD430472@odiug.zope.com>

> HappyDoc doesn't handle nested classes.  (Actually, I'm not sure *any* 
> current Python tool handles nested classes correctly.)

Well, nested classes aren't exactly a recommended idiom in Python...

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


From guido@python.org  Wed Jun 11 15:35:32 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 10:35:32 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: Your message of "Wed, 11 Jun 2003 16:05:40 +0200."
 <3EE73734.9020907@livinglogic.de>
References: <200306090621.h596LgF24277@oma.cosc.canterbury.ac.nz> <3EE4E2F6.2050403@ocf.berkeley.edu> <3EE4EB57.2090803@ocf.berkeley.edu> <3EE62CF8.5040406@livinglogic.de> <3EE64136.6070001@ocf.berkeley.edu>
 <3EE73734.9020907@livinglogic.de>
Message-ID: <200306111435.h5BEZWT30517@odiug.zope.com>

> This could be done automatically, i.e. whenever you call
> PyErr_SetString() etc. the currently active exception will be normalized
> and put into a fourth global variable (exc_cause). In Python code
> whenever a exception handler raises a new exception the exception
> that is currently handled could be set as the cause for this
> exception automatically by the raise statement.

More globals of course defeat the purpose (one of the reasons for
putting the traceback in the exception is to get rid of
sys.exc_traceback).

I also think that doing this automatically whenever PyErr_Set*() is
called would cause a lot of spurious tracebacks.  (Unless the idea is
to skip the chaining if the original exception has an empty traceback;
that will almost always be the case for exceptions raised at the C
level.)  I worry about backwards compatibility.

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



From guido@python.org  Wed Jun 11 15:55:29 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 10:55:29 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: Your message of "Wed, 11 Jun 2003 09:23:56 EDT."
 <5.1.0.14.0.20030611090605.02b46a00@mail.telecommunity.com>
References: <5.1.0.14.0.20030611090605.02b46a00@mail.telecommunity.com>
Message-ID: <200306111455.h5BEtT430588@odiug.zope.com>

[Phillip Eby]
> So, what I want to know is:
> 
> * Do other people find pydoc inadequate?

That's way too strong.  It still does very well for the intended
purpose, which is to extracts docs out of typical library modules.  It
may do poorly on funny things like descriptors and metaclasses, but
esoterica is not its primary goal.

Of course, it's annoying when pydoc raises an exception -- it would be
much better if it simply showed that some info was missing.

In any case, in general I am in favor of a doc tool that scans source
code rather than doing introspection.  There are cases where this
isn't right (e.g. when asking for help about a given object) but when
the object or module isn't already loaded, I think it's wrong to
import the module just to be able to extract its docs.

> * Does it seem likely that PyProtocols would be considered as an addition 
> to the standard library (and by implication, used to document the 
> interfaces of "standard" Python objects)?

I have to admit that every time I try to read your docs, I glaze
over...  Assuming it's yet another way of doing interfaces, I'm wary
of adopting *any* kind of standard approach until I've had much more
time to think over all the issues.

> * Is there anything specific that anybody would want in an overhauled 
> pydoc, that I should know about?

Don't raise exceptions when confronted with objects that violate its
assumptions is my first issue.  A major refactoring to make the code
more understandable and more "obviously correct" would be the second.

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


From pje@telecommunity.com  Wed Jun 11 16:07:48 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Wed, 11 Jun 2003 11:07:48 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <200306111428.h5BESD430472@odiug.zope.com>
References: <Your message of "Wed, 11 Jun 2003 09:03:28 EDT." <5.1.0.14.0.20030611084923.041cce50@mail.telecommunity.com>
 <5.1.1.6.0.20030610200503.02108080@telecommunity.com>
 <5.1.1.6.0.20030610200503.02108080@telecommunity.com>
 <5.1.0.14.0.20030611084923.041cce50@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20030611110414.03329110@telecommunity.com>

At 10:28 AM 6/11/03 -0400, Guido van Rossum wrote:
> > HappyDoc doesn't handle nested classes.  (Actually, I'm not sure *any*
> > current Python tool handles nested classes correctly.)
>
>Well, nested classes aren't exactly a recommended idiom in Python...

The only thing I ever use them for is for defining a descriptor that goes 
inside that class (and isn't used by other classes).  It reads much more 
naturally than defining the descriptors outside the class, and then putting 
them in.



From guido@python.org  Wed Jun 11 16:13:08 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 11:13:08 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: Your message of "Wed, 11 Jun 2003 11:07:48 EDT."
 <5.1.1.6.0.20030611110414.03329110@telecommunity.com>
References: <Your message of "Wed, 11 Jun 2003 09:03:28 EDT." <5.1.0.14.0.20030611084923.041cce50@mail.telecommunity.com> <5.1.1.6.0.20030610200503.02108080@telecommunity.com> <5.1.1.6.0.20030610200503.02108080@telecommunity.com> <5.1.0.14.0.20030611084923.041cce50@mail.telecommunity.com>
 <5.1.1.6.0.20030611110414.03329110@telecommunity.com>
Message-ID: <200306111513.h5BFD8R30802@odiug.zope.com>

> >Well, nested classes aren't exactly a recommended idiom in Python...
> 
> The only thing I ever use them for is for defining a descriptor that
> goes inside that class (and isn't used by other classes).  It reads
> much more naturally than defining the descriptors outside the class,
> and then putting them in.

Whether or not that reads more naturally depends on other factors,
like who is reading the code.

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


From pje@telecommunity.com  Wed Jun 11 16:27:09 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Wed, 11 Jun 2003 11:27:09 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <200306111455.h5BEtT430588@odiug.zope.com>
References: <Your message of "Wed, 11 Jun 2003 09:23:56 EDT." <5.1.0.14.0.20030611090605.02b46a00@mail.telecommunity.com>
 <5.1.0.14.0.20030611090605.02b46a00@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20030611110754.0332a500@telecommunity.com>

At 10:55 AM 6/11/03 -0400, Guido van Rossum wrote:
>[Phillip Eby]
> > So, what I want to know is:
> >
> > * Do other people find pydoc inadequate?
>
>That's way too strong.  It still does very well for the intended
>purpose, which is to extracts docs out of typical library modules.  It
>may do poorly on funny things like descriptors and metaclasses, but
>esoterica is not its primary goal.

Fair enough.


>Of course, it's annoying when pydoc raises an exception -- it would be
>much better if it simply showed that some info was missing.
>
>In any case, in general I am in favor of a doc tool that scans source
>code rather than doing introspection.  There are cases where this
>isn't right (e.g. when asking for help about a given object) but when
>the object or module isn't already loaded, I think it's wrong to
>import the module just to be able to extract its docs.

I agree with you; my goal is to have tools that can do either, but share a 
common framework.  Right now, the tools are split into mutually exclusive 
camps.


> > * Does it seem likely that PyProtocols would be considered as an addition
> > to the standard library (and by implication, used to document the
> > interfaces of "standard" Python objects)?
>
>I have to admit that every time I try to read your docs, I glaze
>over...

Is there anything that you could suggest as to how I could improve 
that?  In our previous discussions regarding the subject matter, you said 
that I made things sound too magical and easy, and I needed to document 
various things such as the requirements for protocol objects.  So, I wrote 
the PyProtocols docs *very* specifically, in order to address your previous 
concern.  That is, to show the "non-magicalness" of it.  It sounds like 
perhaps I went too far to the other extreme.  :)

Anyway, it would be helpful if you (or anyone) could suggest ways to 
improve it.  As I said, I'm seeking feedback, and that definitely includes 
constructive criticism.


>   Assuming it's yet another way of doing interfaces, I'm wary
>of adopting *any* kind of standard approach until I've had much more
>time to think over all the issues.

I understand; you mentioned previously that you didn't want to take an 
approach that would exclude other approaches, so I made sure that 
PyProtocols interoperates "out of the box" with Twisted and Zope, to 
demonstrate that the approach doesn't require a single kind of 
interface.  The docs also include examples of extending the provided 
protocol types to do other things.

Thanks for the feedback and explaining your position.  Now I can make more 
appropriate decisions about where and when to put my efforts.



From pje@telecommunity.com  Wed Jun 11 16:35:01 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Wed, 11 Jun 2003 11:35:01 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <200306111513.h5BFD8R30802@odiug.zope.com>
References: <Your message of "Wed, 11 Jun 2003 11:07:48 EDT." <5.1.1.6.0.20030611110414.03329110@telecommunity.com>
 <Your message of "Wed, 11 Jun 2003 09:03:28 EDT." <5.1.0.14.0.20030611084923.041cce50@mail.telecommunity.com>
 <5.1.1.6.0.20030610200503.02108080@telecommunity.com>
 <5.1.1.6.0.20030610200503.02108080@telecommunity.com>
 <5.1.0.14.0.20030611084923.041cce50@mail.telecommunity.com>
 <5.1.1.6.0.20030611110414.03329110@telecommunity.com>
Message-ID: <5.1.1.6.0.20030611112715.03330520@telecommunity.com>

At 11:13 AM 6/11/03 -0400, Guido van Rossum wrote:
> > >Well, nested classes aren't exactly a recommended idiom in Python...
> >
> > The only thing I ever use them for is for defining a descriptor that
> > goes inside that class (and isn't used by other classes).  It reads
> > much more naturally than defining the descriptors outside the class,
> > and then putting them in.
>
>Whether or not that reads more naturally depends on other factors,
>like who is reading the code.

Of course.  There is a developer who sits a couple of cubicles down from me 
who finds Perl more readable than Python.  :)  I was only commenting on 
*my* use for the idiom, which you once described as "a good use of nested 
namespaces".

I suppose I could start qualifying all my statements with "to me" and "from 
my perspective", but I struggle to keep my verbosity in check as it is.  :)



From staschuk@telusplanet.net  Wed Jun 11 17:31:03 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Wed, 11 Jun 2003 10:31:03 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306111313.h5BDDTj20704@pcp02138704pcs.reston01.va.comcast.net>; from guido@python.org on Wed, Jun 11, 2003 at 09:13:29AM -0400
References: <1055330845.3ee7121d0c36c@mcherm.com> <200306111313.h5BDDTj20704@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20030611103103.C1157@tibia.amotlpaa.bogus>

Quoth Guido van Rossum:
  [...]
> I strongly recommend doing that.  I hereby officially reject PEP 317.

Ok.

I'll certainly add a section on the reasons, with discussion of
the new-style exceptions question, and a summary of other feedback.

  [elsewhere in the thread]
> I've now read the PEP, and it simply fails to explain why implicit
> instantiation sucks so badly as to require all this pain.  The
> arguments of readability and consistency are pretty mild suckage IMO.

My next question, then, is whether those arguments are strong
enough to justify, for example, recommending against implicit
instantiation in PEP 8, or changing the Tutorial's examples.

-- 
Steven Taschuk                                                   w_w
staschuk@telusplanet.net                                      ,-= U
                                                               1 1


From marc@informatik.uni-bremen.de  Wed Jun 11 17:29:40 2003
From: marc@informatik.uni-bremen.de (Marc Recht)
Date: Wed, 11 Jun 2003 18:29:40 +0200
Subject: [Python-Dev] cPickle coredump with 2.3/cvs
Message-ID: <45570000.1055348980@leeloo.intern.geht.de>

--==========893520887==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi!

On NetBSD-current I'm getting this with Python 2.3/cvs (both today's=20
sources).

test_newobj_tuple (__main__.cPickleFastPicklerTests) ... ok

Program received signal SIGSEGV, Segmentation fault.
0xbd9c6bd5 in batch_list (self=3D0x816c6c4, iter=3D0x821145c)
    at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:1477
1477    }

(gdb) bt
#0  0xbd9c6bd5 in batch_list (self=3D0x816c6c4, iter=3D0x821145c)
    at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:1477
#1  0xbd9c7184 in save_list (self=3D0x816c6c4, args=3D0x8211ce4)
    at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:1602
#2  0xbd9c95cd in save (self=3D0x816c6c4, args=3D0x8211ce4, pers_save=3D0)
    at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:2368
#3  0xbd9c6c6e in batch_list (self=3D0x816c6c4, iter=3D0x8211574)
    at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:1506
[... #239]

( configure options: --enable-shared --with-pydebug )

I'm not exactly sure whats happening here, but if there's anything I could=20
do to provide more detail then please let me know.


Regards,
Marc


mundus es fabula
--==========893520887==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (NetBSD)

iD8DBQE+51j17YQCetAaG3MRAukCAJ0c0ivEHZneIsZnqrOGSM4Cf7LtcwCeIvKJ
mY+4Azc6L6M0s9dy4gxFDAo=
=nJXr
-----END PGP SIGNATURE-----

--==========893520887==========--



From guido@python.org  Wed Jun 11 17:30:07 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 12:30:07 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: Your message of "Wed, 11 Jun 2003 10:31:03 MDT."
 <20030611103103.C1157@tibia.amotlpaa.bogus>
References: <1055330845.3ee7121d0c36c@mcherm.com> <200306111313.h5BDDTj20704@pcp02138704pcs.reston01.va.comcast.net>
 <20030611103103.C1157@tibia.amotlpaa.bogus>
Message-ID: <200306111630.h5BGU7O31508@odiug.zope.com>

> > I've now read the PEP, and it simply fails to explain why implicit
> > instantiation sucks so badly as to require all this pain.  The
> > arguments of readability and consistency are pretty mild suckage IMO.
> 
> My next question, then, is whether those arguments are strong
> enough to justify, for example, recommending against implicit
> instantiation in PEP 8, or changing the Tutorial's examples.

I think not.  This is something that each project may decide for
itself.  But I'm at most -0 on this.

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


From mal@lemburg.com  Wed Jun 11 17:33:27 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 11 Jun 2003 18:33:27 +0200
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: <200306111305.h5BD58U20664@pcp02138704pcs.reston01.va.comcast.net>
References: <E19Q0mC-0005Le-00@sc8-pr-cvs1.sourceforge.net> <3EE6E9F6.80902@lemburg.com> <003d01c32ff6$2dad53a0$59b92c81@oemcomputer> <3EE6EFAB.5070301@lemburg.com> <200306111305.h5BD58U20664@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <3EE759D7.9040705@lemburg.com>

Guido van Rossum wrote:
>>>- bool() called without arguments now returns False rather than
>>>  raising an exception.  This is consistent with calling the
>>>  constructors for the other builtin types -- called without argument
>>>  they all return the false value of that type.  (SF patch #724135)
>>
>>I seriously question the usefulness of such an approach. It
>>doesn't seem to buy us anything and is likely to hide typos
>>or progamming errors.
> 
> Types with constructors that insist on an argument are problematic to
> generic code that tries to instantiate a type by simply calling it.

The types we are talking about all define values -- why would you
want to create an object without even knowing the value they
represent ? Can you give an example ?

BTW, your "simply calling the constructor" is a rather dangerous way
of doing inspection: how can you be sure that the constructor
has no side-effects ?

> I don't think that there's much chance that e.g. str() or int() will
> be used by accident and not discovered right away.

How's that ? Since it is perfectly valid to write str() and int()
without arguments, not even the editor can help notice these
cases, so discovery is left to run-time tests and even there
an empty string or a zero value may not always trigger the
programmer's attention.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 11 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        13 days left



From aleaxit@yahoo.com  Wed Jun 11 18:00:47 2003
From: aleaxit@yahoo.com (Alex Martelli)
Date: Wed, 11 Jun 2003 19:00:47 +0200
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306111630.h5BGU7O31508@odiug.zope.com>
References: <1055330845.3ee7121d0c36c@mcherm.com> <20030611103103.C1157@tibia.amotlpaa.bogus> <200306111630.h5BGU7O31508@odiug.zope.com>
Message-ID: <200306111900.47193.aleaxit@yahoo.com>

On Wednesday 11 June 2003 06:30 pm, Guido van Rossum wrote:
> > > I've now read the PEP, and it simply fails to explain why implicit
> > > instantiation sucks so badly as to require all this pain.  The
> > > arguments of readability and consistency are pretty mild suckage IMO.
> >
> > My next question, then, is whether those arguments are strong
> > enough to justify, for example, recommending against implicit
> > instantiation in PEP 8, or changing the Tutorial's examples.
>
> I think not.  This is something that each project may decide for
> itself.  But I'm at most -0 on this.

An official recommendation (either way!) in the style guide would
help -- particularly if the standard library was eventually edited to
follow it.  What's the added value of having, as e.g. is now the case 
in urllib.py, different statements within the same module such as:

raise IOError(e.errno, e.strerror, e.filename)

and then a few lines later:

raise IOError, ('local file error', 'not on local host')

...?  Seems a gratuitous (even though "pretty mild") 'suckage', as
you put it.  What's the objection to Pronouncing on one preferred
style and putting it in the style guide?


Alex



From guido@python.org  Wed Jun 11 18:15:49 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 13:15:49 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: Your message of "Wed, 11 Jun 2003 19:00:47 +0200."
 <200306111900.47193.aleaxit@yahoo.com>
References: <1055330845.3ee7121d0c36c@mcherm.com> <20030611103103.C1157@tibia.amotlpaa.bogus> <200306111630.h5BGU7O31508@odiug.zope.com>
 <200306111900.47193.aleaxit@yahoo.com>
Message-ID: <200306111715.h5BHFnK31733@odiug.zope.com>

[Alex]
> An official recommendation (either way!) in the style guide would
> help -- particularly if the standard library was eventually edited to
> follow it.  What's the added value of having, as e.g. is now the case 
> in urllib.py, different statements within the same module such as:
> 
> raise IOError(e.errno, e.strerror, e.filename)
> 
> and then a few lines later:
> 
> raise IOError, ('local file error', 'not on local host')
> 
> ...?  Seems a gratuitous (even though "pretty mild") 'suckage', as
> you put it.  What's the objection to Pronouncing on one preferred
> style and putting it in the style guide?

The inconsistency you note in urllib.py is already frowned upon by the
general style guideline "consistency with immediately surrounding code
is valued more than consistency with the style guide".

A pronouncement, no matter how mild, would mean that the other style
is "wrong", and this would then cause a flurry of noise checkins of
people trying to "fix" the "wrong" code, probably introducing some
bugs in the hurry, if our experience with past flurries of style
consistency checkins is any measure.

I really don't think that

  raise IOError("message")

should always be favored over

  raise IOError, "message"

I find the latter a tad prettier (less punctuation!) even though the
former is preferred when the message is too long to comfortably fit on
a line.

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


From guido@python.org  Wed Jun 11 19:18:23 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 14:18:23 -0400
Subject: [Python-Dev] cPickle coredump with 2.3/cvs
In-Reply-To: Your message of "Wed, 11 Jun 2003 18:29:40 +0200."
 <45570000.1055348980@leeloo.intern.geht.de>
References: <45570000.1055348980@leeloo.intern.geht.de>
Message-ID: <200306111818.h5BIIND08526@odiug.zope.com>

> On NetBSD-current I'm getting this with Python 2.3/cvs (both today's=20
> sources).
> 
> test_newobj_tuple (__main__.cPickleFastPicklerTests) ... ok
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xbd9c6bd5 in batch_list (self=3D0x816c6c4, iter=3D0x821145c)
>     at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:1477
> 1477    }
> 
> (gdb) bt
> #0  0xbd9c6bd5 in batch_list (self=3D0x816c6c4, iter=3D0x821145c)
>     at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:1477
> #1  0xbd9c7184 in save_list (self=3D0x816c6c4, args=3D0x8211ce4)
>     at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:1602
> #2  0xbd9c95cd in save (self=3D0x816c6c4, args=3D0x8211ce4, pers_save=3D0)
>     at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:2368
> #3  0xbd9c6c6e in batch_list (self=3D0x816c6c4, iter=3D0x8211574)
>     at /home/marc/work/cvs/python/dist/src/Modules/cPickle.c:1506
> [... #239]
> 
> ( configure options: --enable-shared --with-pydebug )
> 
> I'm not exactly sure whats happening here, but if there's anything I could=20
> do to provide more detail then please let me know.

I can't reproduce this on Linux with the the CVS head.  But it looks
(from the cryptic "[... #239]" part) that you may have a stack
overflow.  Can you see if increasing the stack limit makes the problem
go away?  (I wish I could tell you how to increase the stack limit,
but that depends on your shell and OS; using Bash on Linux, I think
"ulimit -s 9999" set the stack to 9999*1024 bytes.

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


From martin@v.loewis.de  Wed Jun 11 19:59:38 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 11 Jun 2003 20:59:38 +0200
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <200306111301.h5BD1q220645@pcp02138704pcs.reston01.va.comcast.net>
References: <16E1010E4581B049ABC51D4975CEDB88619A95@UKDCX001.uk.int.atosorigin.com>
 <200306111301.h5BD1q220645@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <m3wufs1lut.fsf@mira.informatik.hu-berlin.de>

<aol>
Me too.
</aol>

Martin

> > > "Phillip J. Eby" <pje@telecommunity.com> writes:
> >=20
> > >> I hope to have some cycles soon to work on such a framework, but sin=
ce
> > >> it effectively depends on both PEP 246 and an unwritten PEP for a
> > >> "protocol declaration API" like the one in PyProtocols, it would be
> > >> good to get some idea of whether the Python developer community feels
> > >> this is a good direction for me to pursue.
> >=20
> > From: Martin v. L=C2=8E=C3=B6wis [mailto:martin@v.loewis.de]
> > > I'm quite skeptical about "grand new architectures" whose development
> > > starts off with "what we have is rubbish". In my experience, the
> > > rubbish that we have right now continues to be much better than what
> > > the grand new architecture can deliver for several years to come. So I
> > > would always favour evolution over revolution.
> >=20
> [Paul Moore]
> > To some extent I agree with this. I haven't taken the time to *fully*
> > digest the adaptation PEP or Phillip's protocol ideas, but my general
> > impression is that they hover somewhere on the border. Their proponents
> > describe them as if they were grand new architectures, with an
> > implication of "let's rewrite everything" because "what we have is
> > rubbish" (as you say).
> >=20
> > But in practice, I can't see anything in either of these proposals which
> > really needs much change to what we currently have. I suspect that the
> > reality is that they are more or less descriptions of "useful patterns"
> > which can be used to offer a standard answer to issues which sometimes
> > come up with current methods, but which aren't frequent or severe enough
> > to justify major angst. (For example, the old one about what precisely
> > constitutes a "file-like" object in a given context). In this context,
> > it's not entirely clear to me why the proposals need "official sanction=
",
> > as opposed to simply being made available as user-level libraries, with
> > the possibility of migrating to "standard" status if the level of inter=
est
> > proves to justify it.
> >=20
> > As usual, I suspect the reality is somewhere between these two extremes.
> > But I'd like to see the two proposals restated in the form of working
> > library code. Then I could *try* them rather than arguing about theory.
> > [Of course if there really *is* a need for language support, this would
> > focus on the *exact* language change needed, along with a real use case
> > to justify it.]
>=20
> Well said.



From drifty@alum.berkeley.edu  Wed Jun 11 21:26:50 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Wed, 11 Jun 2003 13:26:50 -0700
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <000001c32fd0$978b55e0$9b07a044@oemcomputer>
References: <3EE66F37.3040700@ocf.berkeley.edu> <200306110030.h5B0UQA17243@pcp02138704pcs.reston01.va.comcast.net> <000001c32fd0$978b55e0$9b07a044@oemcomputer>
Message-ID: <3EE7908A.4010405@ocf.berkeley.edu>

Raymond Hettinger wrote:
>>>Bug 729103 discovered an interesting little issue; 'super' instances 
>>>cause inspect.isroutine to return True since it also poses as a non-data 
>>>descriptor.  Now this is bad because pydoc then tries to get a __name__ 
>>>attribute out of it which it lacks because it is an instance of a class 
>>>and not really a function or method.
>>>
>>>So, should I change inspect.isroutine to check to see if its argument is 
>>>an instance of 'super'?  
> 
> 
> That is a reasonable short-term solution but it should go 
> one layer down in ismethoddescriptor().  Append the line:
> 
>     and not isinstance(object, super)
>

Even though it is a non-data descriptor?  It seems to have a __get__ 
instead of a __call__ method.  The problem is that pydoc just classifies 
it as a descriptor first and assumes __name__ will be there.

-Brett




From marc@informatik.uni-bremen.de  Wed Jun 11 21:59:58 2003
From: marc@informatik.uni-bremen.de (Marc Recht)
Date: Wed, 11 Jun 2003 22:59:58 +0200
Subject: [Python-Dev] cPickle coredump with 2.3/cvs
In-Reply-To: <200306111818.h5BIIND08526@odiug.zope.com>
References: <45570000.1055348980@leeloo.intern.geht.de>
 <200306111818.h5BIIND08526@odiug.zope.com>
Message-ID: <4670000.1055365198@leeloo.intern.geht.de>

--==========1810459384==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> I can't reproduce this on Linux with the the CVS head.  But it looks
> (from the cryptic "[... #239]" part) that you may have a stack
I meant that there haven been more (mostly) similiar lines. If it helps I=20
could upload a complete stacktrace to SourceForge and/or send it via email.
> overflow.  Can you see if increasing the stack limit makes the problem
> go away?  (I wish I could tell you how to increase the stack limit,
This happened with a stack size of 32kb, so that shouldn't be the problem.

Regards,
Marc

mundus es fabula
--==========1810459384==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (NetBSD)

iD8DBQE+55hV7YQCetAaG3MRAjwaAKCNfNMSfGVoY+5gflkI43zmjaK6qACeMd6y
QtVrw11KWTDguN+VmNqrCe8=
=dZUF
-----END PGP SIGNATURE-----

--==========1810459384==========--



From guido@python.org  Wed Jun 11 22:09:28 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 17:09:28 -0400
Subject: [Python-Dev] cPickle coredump with 2.3/cvs
In-Reply-To: Your message of "Wed, 11 Jun 2003 22:59:58 +0200."
 <4670000.1055365198@leeloo.intern.geht.de>
References: <45570000.1055348980@leeloo.intern.geht.de> <200306111818.h5BIIND08526@odiug.zope.com>
 <4670000.1055365198@leeloo.intern.geht.de>
Message-ID: <200306112109.h5BL9SE09821@odiug.zope.com>

> > I can't reproduce this on Linux with the the CVS head.  But it looks
> > (from the cryptic "[... #239]" part) that you may have a stack
> I meant that there haven been more (mostly) similiar lines. If it helps I=20
> could upload a complete stacktrace to SourceForge and/or send it via email.
> > overflow.  Can you see if increasing the stack limit makes the problem
> > go away?  (I wish I could tell you how to increase the stack limit,
> This happened with a stack size of 32kb, so that shouldn't be the problem.

Whaaaa?  That's a ridiculously small stack size!  Why couldn't that be
the problem?

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


From marc@informatik.uni-bremen.de  Wed Jun 11 22:16:09 2003
From: marc@informatik.uni-bremen.de (Marc Recht)
Date: Wed, 11 Jun 2003 23:16:09 +0200
Subject: [Python-Dev] cPickle coredump with 2.3/cvs
In-Reply-To: <200306112109.h5BL9SE09821@odiug.zope.com>
References: <45570000.1055348980@leeloo.intern.geht.de>
 <200306111818.h5BIIND08526@odiug.zope.com>
 <4670000.1055365198@leeloo.intern.geht.de>
 <200306112109.h5BL9SE09821@odiug.zope.com>
Message-ID: <17610000.1055366169@leeloo.intern.geht.de>

--==========864570887==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> Whaaaa?  That's a ridiculously small stack size!  Why couldn't that be
> the problem?
Oops! Sorry, typo.. It's 32mb.

Regards,
Marc

mundus es fabula
--==========864570887==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (NetBSD)

iD8DBQE+55wZ7YQCetAaG3MRAtkUAJ9hwip/AReYv59iPbYRTF2/qTmyQwCgjTK8
wT+LdGlho6Zw84Mr4Kc7wH8=
=sG0F
-----END PGP SIGNATURE-----

--==========864570887==========--



From marc@informatik.uni-bremen.de  Wed Jun 11 22:43:16 2003
From: marc@informatik.uni-bremen.de (Marc Recht)
Date: Wed, 11 Jun 2003 23:43:16 +0200
Subject: [Python-Dev] cPickle coredump with 2.3/cvs
In-Reply-To: <45570000.1055348980@leeloo.intern.geht.de>
References: <45570000.1055348980@leeloo.intern.geht.de>
Message-ID: <32890000.1055367796@leeloo.intern.geht.de>

--==========1714602778==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> On NetBSD-current I'm getting this with Python 2.3/cvs (both today's
> sources).
I forgot to mention that the cPickle test runs flawlessly with Python 2.2.3 =

on the same box.
and "ulimit -a" :

cpu time (seconds)         unlimited
file size (blocks)         unlimited
data seg size (kbytes)     1048576
stack size (kbytes)        32768
core file size (blocks)    unlimited
resident set size (kbytes) 1533876
locked-in-memory size (kb) 1533876
processes                  2068
file descriptors           6668

HTH,
Marc

--==========1714602778==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (NetBSD)

iD8DBQE+56J07YQCetAaG3MRAofsAJ9BJw2/k7eRa9bSzgM53boBr0YqsQCcCQgk
iVUm2L8LZqCgq4bPRh2yBF0=
=MQ8Z
-----END PGP SIGNATURE-----

--==========1714602778==========--



From guido@python.org  Wed Jun 11 23:02:09 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 11 Jun 2003 18:02:09 -0400
Subject: [Python-Dev] cPickle coredump with 2.3/cvs
In-Reply-To: Your message of "Wed, 11 Jun 2003 23:43:16 +0200."
 <32890000.1055367796@leeloo.intern.geht.de>
References: <45570000.1055348980@leeloo.intern.geht.de>
 <32890000.1055367796@leeloo.intern.geht.de>
Message-ID: <200306112202.h5BM29X10080@odiug.zope.com>

> > On NetBSD-current I'm getting this with Python 2.3/cvs (both today's
> > sources).
> I forgot to mention that the cPickle test runs flawlessly with Python 2.2.3
> on the same box.

OK, go debug it.  I'm stumped.  It only occurs on your system.  A full
traceback won't help much -- you'll have to dig through the data to
find out what's wrong, I'm afraid... :-(

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


From python@rcn.com  Wed Jun 11 23:12:52 2003
From: python@rcn.com (Raymond Hettinger)
Date: Wed, 11 Jun 2003 18:12:52 -0400
Subject: [Python-Dev] Sneaky 'super' instances
References: <3EE66F37.3040700@ocf.berkeley.edu> <200306110030.h5B0UQA17243@pcp02138704pcs.reston01.va.comcast.net> <000001c32fd0$978b55e0$9b07a044@oemcomputer> <3EE7908A.4010405@ocf.berkeley.edu>
Message-ID: <005501c33066$9a24b440$125ffea9@oemcomputer>

[Raymond]
> > That is a reasonable short-term solution but it should go 
> > one layer down in ismethoddescriptor().  Append the line:
> > 
> >     and not isinstance(object, super)
> >

[Brett]
> Even though it is a non-data descriptor?  It seems to have a __get__ 
> instead of a __call__ method.  The problem is that pydoc just classifies 
> it as a descriptor first and assumes __name__ will be there.

Either way is fine.

My way solves the original problem and defines methoddescriptor
as a non-data descriptor that isn't super.  I think that matches what 
people expect when calling that inspect.ismethoddescriptor().

OTOH, if methoddescriptor is viewed as synonymous with
non-data descriptor, then, technically a super object should
return True and your fix will have to go inspect.isroutine().

Name your poison.  Add a test case.  Then fix it.


Raymond



From drifty@alum.berkeley.edu  Wed Jun 11 23:24:01 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Wed, 11 Jun 2003 15:24:01 -0700
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <005501c33066$9a24b440$125ffea9@oemcomputer>
References: <3EE66F37.3040700@ocf.berkeley.edu> <200306110030.h5B0UQA17243@pcp02138704pcs.reston01.va.comcast.net> <000001c32fd0$978b55e0$9b07a044@oemcomputer> <3EE7908A.4010405@ocf.berkeley.edu> <005501c33066$9a24b440$125ffea9@oemcomputer>
Message-ID: <3EE7AC01.10005@ocf.berkeley.edu>

Raymond Hettinger wrote:
> [Raymond]
> 
>>>That is a reasonable short-term solution but it should go 
>>>one layer down in ismethoddescriptor().  Append the line:
>>>
>>>    and not isinstance(object, super)
>>>
> 
> 
> [Brett]
> 
>>Even though it is a non-data descriptor?  It seems to have a __get__ 
>>instead of a __call__ method.  The problem is that pydoc just classifies 
>>it as a descriptor first and assumes __name__ will be there.
> 
> 
> Either way is fine.
> 

Then how about both; I patch pydoc, you patch inspect?

> My way solves the original problem and defines methoddescriptor
> as a non-data descriptor that isn't super.  I think that matches what 
> people expect when calling that inspect.ismethoddescriptor().
> 

I never use inspect so if you think that it should be changed that way 
then go for it.

> OTOH, if methoddescriptor is viewed as synonymous with
> non-data descriptor, then, technically a super object should
> return True and your fix will have to go inspect.isroutine().
> 

I decided to catch AttributeError when pydoc checks to see what kind of 
thing an object is and then just pass on the catch and fall through to 
the method it has for when it isn't a module, class, or routine.

> Name your poison.  Add a test case.  Then fix it.

Ah, but there are no tests for pydoc.

-Brett



From Jennifer" <uziczqywl@cyklop.nada.kth.se  Wed Jun 11 22:20:55 2003
From: Jennifer" <uziczqywl@cyklop.nada.kth.se (Jennifer)
Date: Wed, 11 Jun 2003 15:20:55 -0600
Subject: [Python-Dev] more power for your digital cable
Message-ID: <df2601c3305f$57d43fe0$3c5889ef@"Jennifer" uziczqywl>

------=_NextPart_8F8_1EBF_03F9E199.113CF543
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


------=_NextPart_8F8_1EBF_03F9E199.113CF543
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D=22Content-Type=22 CONTENT=3D=22text/html;charset=3Di=
so-8859-1=22>
<=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22>
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D=22text/html; charset=3Diso-8=
859-1=22>
<META content=3D=22MSHTML 6.00.2600.0=22 name=3DGENERATOR>
<STYLE></STYLE>
</HEAD><FONT face=3DArial><FONT size=3D2>
<BODY>
<DIV>
<DIV>
<DIV><STRONG>The next big thing for digital cable users?&nbsp; <A 
href=3D=22http://www.vogue-to.com/digitool/index.php?RepID=3DRS=22>Find=
 out more 
..</A></STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D=23808080 size=3D1>If you don't want any more emails=
 from us, 
</FONT><A href=3D=22http://www.vogue-to.com/digitool/cleanlist.php=22><=
FONT color=3D=23808080 
size=3D1>go here</FONT></A></DIV></DIV></DIV></BODY></HTML></FONT></FON=
T>

------=_NextPart_8F8_1EBF_03F9E199.113CF543--



From andrewm@object-craft.com.au  Thu Jun 12 03:05:03 2003
From: andrewm@object-craft.com.au (Andrew McNamara)
Date: Thu, 12 Jun 2003 12:05:03 +1000
Subject: [Python-Dev] Patch to remove eval from csv sniffer
Message-ID: <20030612020503.5D8DD3C41B@coffee.object-craft.com.au>

The patch by Raymond Hettinger mentioned here:

    www.python.org/sf/744104

makes a lot of sense. The question is - should it be applied now? We're
in the 55th minute of the 11th hour for 2.3, and changes are generally
unwelcome. This change changes the sniffer's behaviour slightly, but
it's probably better to do this now, than after 2.3 is released (and
it's a potential security problem).

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/


From tismer@tismer.com  Thu Jun 12 03:25:47 2003
From: tismer@tismer.com (Christian Tismer)
Date: Thu, 12 Jun 2003 04:25:47 +0200
Subject: [Python-Dev] Proposal to drop f_tstate
Message-ID: <3EE7E4AB.8030909@tismer.com>

Dear developers,

For years, there has been a f_tstate field in frames.

During my implementation of thread pickling for Stackless,
I investigated how much use is made of this field.
I found out that it is only used in rare cases, only, and can
be most probably replaced by PyThreadState_GET() in the
six or seven cases where it is touched at all.

f_tstate would make sense if PyThreadState_GET() wasn't
such a cheap macro. It also would make sense if it were used
somewhere to assure proper allocation of a frame to its tstate.
But this is nowhere used.
In the case of Stackless, f_tstate turns out to be even a
drawback, since non-recursively called frames can be freely
moved between real threads, and I'm saving updates to f_tstate
already, simply by removing it.

I also didn't find any external module that uses f_tstate.

Therefore, I hereby propose to remove this frame field,
in order to save space.

I also offer to provide the simple patch, right now.

cheers -- chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/




From skip@pobox.com  Thu Jun 12 03:27:07 2003
From: skip@pobox.com (Skip Montanaro)
Date: Wed, 11 Jun 2003 21:27:07 -0500
Subject: [Python-Dev] Patch to remove eval from csv sniffer
In-Reply-To: <20030612020503.5D8DD3C41B@coffee.object-craft.com.au>
References: <20030612020503.5D8DD3C41B@coffee.object-craft.com.au>
Message-ID: <16103.58619.49067.883421@montanaro.dyndns.org>

    Andrew> The patch by Raymond Hettinger mentioned here:
    Andrew>     http://www.python.org/sf/744104

    Andrew> makes a lot of sense. The question is - should it be applied
    Andrew> now?

I know it's late in the cycle, but the sniffer hasn't really been exposed to
the outside world, so I doubt we'd break any existing applications.  I
attached a comment to the patch with a couple minor suggestions.

Skip


From greg@cosc.canterbury.ac.nz  Thu Jun 12 04:02:02 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Jun 2003 15:02:02 +1200 (NZST)
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135
In-Reply-To: <003d01c32ff6$2dad53a0$59b92c81@oemcomputer>
Message-ID: <200306120302.h5C322U03138@oma.cosc.canterbury.ac.nz>

> - bool() called without arguments now returns False rather than
>   raising an exception.  This is consistent with calling the
>   constructors for the other builtin types -- called without argument
>   they all return the false value of that type.  (SF patch #724135)

That's clearly useful for mutable types such as lists
and dicts, but for immutable types? Especially one such
as bool whose possible values are so, er, symmetrical
in prominence (is there a succinct word for this
concept?)

Does anyone have a use case for this?

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


From greg@cosc.canterbury.ac.nz  Thu Jun 12 04:42:42 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Jun 2003 15:42:42 +1200 (NZST)
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <200306111312.h5BDCZk20687@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <200306120342.h5C3ggM03207@oma.cosc.canterbury.ac.nz>

> (1) The syntax to catch multiple exceptions causes common mistakes
>     like this:
> 
>     try:
>         <some indexing operation>
>     except KeyError, IndexError:
>         <error handling>

If a keyword is added to the raise syntax for specifying a
traceback, the same thing should probably be done for catching
it as well, e.g.

  try:
    ...
  except SomeError traceback tb:
    ...

and then the above problem would go away:

    try:
        <some indexing operation>
    except KeyError, IndexError traceback tb:
        <error handling>

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


From fdrake@acm.org  Thu Jun 12 04:46:03 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Wed, 11 Jun 2003 23:46:03 -0400
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <200306120342.h5C3ggM03207@oma.cosc.canterbury.ac.nz>
References: <200306111312.h5BDCZk20687@pcp02138704pcs.reston01.va.comcast.net>
 <200306120342.h5C3ggM03207@oma.cosc.canterbury.ac.nz>
Message-ID: <16103.63355.265252.149108@grendel.zope.com>

Greg Ewing writes:
 > If a keyword is added to the raise syntax for specifying a
 > traceback, the same thing should probably be done for catching
 > it as well, e.g.
 > 
 >   try:
 >     ...
 >   except SomeError traceback tb:
 >     ...
 > 
 > and then the above problem would go away:
 > 
 >     try:
 >         <some indexing operation>
 >     except KeyError, IndexError traceback tb:
 >         <error handling>

Except... what you're expecting to be a traceback here isn't.  It's
the exception instance.  The traceback comes from sys.exc_info()[2].


  -Fred

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


From greg@cosc.canterbury.ac.nz  Thu Jun 12 05:12:26 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Jun 2003 16:12:26 +1200 (NZST)
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: <200306111305.h5BD58U20664@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz>

Guido:

> Types with constructors that insist on an argument are problematic to
> generic code that tries to instantiate a type by simply calling it.

Why on earth would you be trying to instantiate something
without having any idea what parameters are required?

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


From greg@cosc.canterbury.ac.nz  Thu Jun 12 05:28:59 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Jun 2003 16:28:59 +1200 (NZST)
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306111435.h5BEZWT30517@odiug.zope.com>
Message-ID: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>

Guido:

> More globals of course defeat the purpose (one of the reasons for
> putting the traceback in the exception is to get rid of
> sys.exc_traceback).

I think the idea was that this would be a C-level global,
not a Python one (i.e. part of the existing group of
C variables representing the current exception state).

> I also think that doing this automatically whenever PyErr_Set*() is
> called would cause a lot of spurious tracebacks.  (Unless the idea is
> to skip the chaining if the original exception has an empty
> traceback

I don't understand that. What is a "spurious" traceback? And how
are you going to get one if the current traceback is empty?

> I worry about backwards compatibility.

What would this break? Code which doesn't know about chained
exceptions can just ignore the new attribute and get exactly
the information they used to get from the exception and its
traceback, as far as I can see.

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


From greg@cosc.canterbury.ac.nz  Thu Jun 12 05:31:50 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Jun 2003 16:31:50 +1200 (NZST)
Subject: [Python-Dev] cPickle coredump with 2.3/cvs
In-Reply-To: <17610000.1055366169@leeloo.intern.geht.de>
Message-ID: <200306120431.h5C4Voe03303@oma.cosc.canterbury.ac.nz>

Marc Recht <marc@informatik.uni-bremen.de>:

> Oops! Sorry, typo.. It's 32mb.

32 millibytes? Sounds a bit small to me... :-)

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


From greg@cosc.canterbury.ac.nz  Thu Jun 12 05:45:03 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Jun 2003 16:45:03 +1200 (NZST)
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <16103.63355.265252.149108@grendel.zope.com>
Message-ID: <200306120445.h5C4j3R03345@oma.cosc.canterbury.ac.nz>

> Except... what you're expecting to be a traceback here isn't.  It's
> the exception instance.

Oops, you're right. I'm not thinking straight today.

Looks like we need *another* keyword in there:

  except KeyError, IndexError as e:
    ...

And, of course, if we're storing the traceback as an attribute of the
exception, we don't need a keyword for catching it at all.

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


From tim_one@email.msn.com  Thu Jun 12 05:50:57 2003
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 12 Jun 2003 00:50:57 -0400
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEAAENAB.tim_one@email.msn.com>

[Guido]
>> Types with constructors that insist on an argument are problematic to
>> generic code that tries to instantiate a type by simply calling it.

[Greg Ewing]
> Why on earth would you be trying to instantiate something
> without having any idea what parameters are required?

For example, unpickling can need to do this when a type uses the
__getstate__ + __setstate__ pickle subsystem (it has to create an object of
the correct type before it can call that object's __setstate__ method; if
the type's constructor requires arguments, life is harder).  The generic
code in copy.py faces related problems (you may well be able to mimic the
full current state of an object without having any idea how to build the
object up from scratch "correctly"; for example,

    shallowcopy = obj.__class__()
    shallowcopy.__dict__.update(obj.__dict__)

works fine for instances of classic classes, provided the constructor
doesn't require arguments).



From greg@cosc.canterbury.ac.nz  Thu Jun 12 05:57:49 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Thu, 12 Jun 2003 16:57:49 +1200 (NZST)
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: <LNBBLJKPBEHFEDALKOLCOEAAENAB.tim_one@email.msn.com>
Message-ID: <200306120457.h5C4vn503385@oma.cosc.canterbury.ac.nz>

Tim:

> [Greg Ewing]
> > Why on earth would you be trying to instantiate something
> > without having any idea what parameters are required?
> 
> For example, unpickling can need to do this when a type uses the
> __getstate__ + __setstate__ pickle subsystem 

But that can't possibly work for immutable types.

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


From Paul.Moore@atosorigin.com  Thu Jun 12 11:16:39 2003
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu, 12 Jun 2003 11:16:39 +0100
Subject: [Python-Dev] Sneaky 'super' instances
Message-ID: <16E1010E4581B049ABC51D4975CEDB88619A97@UKDCX001.uk.int.atosorigin.com>

From: Phillip J. Eby [mailto:pje@telecommunity.com]

> PEP 246 has a chicken-and-egg problem, because it's only useful if
> it's being used. adapt() by itself isn't at all useful if you don't
> have components or protocols that support it. And nobody wants to
> write components or protocols to support it, if nobody is using
> adapt(). If I understand Alex and Clark's intentions in writing the
> PEP, it was to get adapt() to have a ubiquitous presence, so that
> authors could assume their users would be able to use it.

Um. I don't think that makes sense. My reading of PEP 246 seems to
show that the authors were fully aware of the problem with requiring
widespread support before the technique is useful. Specifically,
requirement (e) in the PEP considers precisely the case where neither
the "protocol" nor the "object" need to know about the adapt()
mechanism. Sadly, the reference implementation provided does not
support requirement (e).

As I understand PEP 246, its basic idea is that an application (such
as a pydoc rewrite, to focus on your specific example) can be written
based round concrete "protocol" classes which encapsulate all of the
assumptions being made. These protocol classes can have __adapt__
methods to define how the built in and standard library types do or
do not conform to the protocol. This gives an application which works
unmodified for core Python.

Now, user-defined classes can be written to "support" the application,
by having __conform__ methods to qualify if and how the types match
the application's protocols.

And for existing user-defined classes (or new ones where you don't want
to put knowledge of this application into the class) the "registry"
approach works.

Actually, this analysis makes me wonder a bit about the PEP. The
__adapt__ method seems reasonable for encapsulating knowledge about
built-in types, although in practice it may not work as well as it
would seem at first glance. There's an implication that protocols
don't need to be "special", but can be ordinary classes - the
canonical example would be adapt(obj, file) to "make" obj a file-
like object, if possible. But "real" classes won't have __adapt__
methods...

The __conform__ method seems unlikely to be useful in practice -
it's the usual issue of having to change the class to support a new
protocol.

The registry idea might work (but it's not implemented). However, it
would seem to depend on someone, somewhere, doing the registering. I
can see things like::

    import numarray
    import register_numarray_adapters_to_pydoc
    import pygame
    import register_pygame_adapters_to_pydoc

[And this assumes that the registration happens in __init__.py
import-time magic, which is arguably bad practice, so maybe you need
an extra register() call for each of these]

... anyway - enough theoretical analysis of PEP 246. Hopefully, I
have demonstrated the point that it needs "real world" use to expose
any issues.

> Two years after the original PEP, I saw a way to make use of it in
> a framework I was working on, and then noticed the chicken-and-egg
> problem.

I think the PEP's intent was that you can write the necessary adapters
for types you know of, and then your users can add adapters (or ask
you to add them) as required.

> But, one thing that had changed since then was that Twisted and
> Zope both had significant "interface" packages. I saw a way to
> unite them, using PEP 246 as a mechanism, and how to make a toolkit
> that would allow developers to use adapt() in their own programs,
> without having to wait for anybody else to adopt adapt(). I'm hoping
> this will end the chicken-and-egg problem for PEP 246, as well as
> increase interoperability between frameworks.

I don't believe that there should be a chicken-and-egg problem
(if there is, PEP 246 is doomed to failure IMHO). But if you can
do something like this and eliminate what you see as the problem,
that's great. But if you do it at the cost of a *new* chicken-and-egg
problem, you've achieved nothing...

> There is no need for language-level support; it's just a library.
> And, PyProtocols, my PEP 246 implementation and extension, is
> available for download now.

If PyProtocols is a PEP 246 implementation, then that's something I'm
interested in. I assume that it has no chicken-and-egg issue (as I
don't see one in PEP 246 itself). Off to download and investigate...

> See, I could probably write the documentation tool faster if I used
> PEAK, my application framework. But that would make it unlikely to
> ever be usable for the Python standard library, because that would
> be like distributing Zope in the standard library.

That's a tough call. Only you can answer that, but if you work
from the basis that pydoc is your "competition", the question is
whether you can convince existing satisfied users of pydoc that your
replacement is "better". In other words, are you willing to "sell"
your replacement to sceptical users? If not, then don't waste your
time making your development job harder.

> In effect, my question is, "Should I expend the extra effort to
> develop the documentation tool in such a way that it could easily
> be distributed with the standard library?" And, since the tool
> would have to depend on PyProtocols, this means that (in effect)
> PyProtocols would have to be accepted for the standard library.

If PyProtocols is just PEP 246, then you're just another voice (and
one who's got useful code to contribute) arguing for PEP 246. If it's
more, you'll have to explain *what* there is that's extra, and *why*
it's necessary. And you're effectively arguing against PEP 246, as
being insufficient for its stated purpose, so you'll have to justify
that, too.

> So, what I want to know is:

> * Do other people find pydoc inadequate?

No real sign of that. I don't. But my use is minimal, and I suspect
that's true of many people. If pydoc broke on something subtle
(like super()) then I'd view it as a minor irritation and move on.
(Particularly as pydoc is a command line tool, rather than a program
library).

> * Does it seem likely that PyProtocols would be considered as an
> addition to the standard library (and by implication, used to
> document the interfaces of "standard" Python objects)?

a) Less likely than that PEP 246 would be (assuming it's "more" than
   PEP246). And PEP 246 is struggling for lack of real use cases (no,
   I don't believe that it's a chicken-and-egg issue, more that people
   are happy implementing their own solution, either because they
   don't know of PEP 246 or because it's got problems that haven't
   been teased out by real use yet).

b) I'm not sure what you're implying by documenting interfaces. PEP
   246 is clearly *not* about standardising (documenting) interfaces,
   but about adapting to more fluid "real life" situations - package
   XXX needs a file-like object, but only cares about readline, seek
   and tell methods, but package YYY needs a file-like object with
   read and write methods (but doesn't care about seekability). It
   sounds like PyProtocols carries more baggage (a point against it).

> * Is there anything specific that anybody would want in an
> overhauled pydoc, that I should know about?

Doesn't look like it. Guido expressed an interest in "less implicit
assumptions" but that sounds to me more like an implementation issue
than a user-level requirement.

Sorry, that went on a bit. Hope it helped.
Paul.


From mwh@python.net  Thu Jun 12 11:27:56 2003
From: mwh@python.net (Michael Hudson)
Date: Thu, 12 Jun 2003 11:27:56 +0100
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz> (Greg
 Ewing's message of "Thu, 12 Jun 2003 16:28:59 +1200 (NZST)")
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
Message-ID: <2mptlj615f.fsf@starship.python.net>

Greg Ewing <greg@cosc.canterbury.ac.nz> writes:

> Guido:
>
>> More globals of course defeat the purpose (one of the reasons for
>> putting the traceback in the exception is to get rid of
>> sys.exc_traceback).
>
> I think the idea was that this would be a C-level global,
> not a Python one (i.e. part of the existing group of
> C variables representing the current exception state).

Those are fields in the thread state, not globals, IIRC.

Cheers,
M>

-- 
  Good? Bad? Strap him into the IETF-approved witch-dunking
  apparatus immediately!                        -- NTK now, 21/07/2000


From Paul.Moore@atosorigin.com  Thu Jun 12 11:29:48 2003
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu, 12 Jun 2003 11:29:48 +0100
Subject: [Python-Dev] Sneaky 'super' instances
Message-ID: <16E1010E4581B049ABC51D4975CEDB88619A98@UKDCX001.uk.int.atosorigin.com>

From: Moore, Paul=20
> Specifically, requirement (e) in the PEP considers precisely
> the case where neither the "protocol" nor the "object" need
> to know about the adapt() mechanism. Sadly, the reference
> implementation provided does not support requirement (e).

And doubly sadly, I see that PyProtocols doesn't either. I'd
suggest that you add this, and then maybe your "chicken and egg"
issues will go away. Or maybe I've missed something :-)

Paul.


From walter@livinglogic.de  Thu Jun 12 11:44:19 2003
From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Thu, 12 Jun 2003 12:44:19 +0200
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
Message-ID: <3EE85983.5040703@livinglogic.de>

Greg Ewing wrote:

> Guido:
> 
>>More globals of course defeat the purpose (one of the reasons for
>>putting the traceback in the exception is to get rid of
>>sys.exc_traceback).
> 
> I think the idea was that this would be a C-level global,
> not a Python one (i.e. part of the existing group of
> C variables representing the current exception state).

Exactly. We'd only need this as sys.exc_cause, if we implemented
exception chaining before moving the traceback into the exception.

So maybe the plan should look somethink like this:

1. Deprecate string exceptions.

2. Make Exception a new-style class.

3. Require exceptions to be derived from Exception.

4. Make the traceback an attribute of the exception object.

5. Implement exception chaining (as an attribute named cause on
    the outer exception referencing the inner exception).

6. Add other exception attributes (e.g. KeyError has an attribute
    key, IndexError has an attribute index, IOError has attributes
    filename, errorcode etc.)

Is there anything else that should go into the new exception PEP?
(No, I'm not volunteering to write it. ;) Maybe it should be split
into multiple PEPs?)

> [...]

Bye,
    Walter Dörwald




From aahz@pythoncraft.com  Thu Jun 12 12:31:54 2003
From: aahz@pythoncraft.com (Aahz)
Date: Thu, 12 Jun 2003 07:31:54 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <3EE85983.5040703@livinglogic.de>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz> <3EE85983.5040703@livinglogic.de>
Message-ID: <20030612113154.GA9196@panix.com>

On Thu, Jun 12, 2003, Walter D=F6rwald wrote:
>
> So maybe the plan should look somethink like this:
>=20
> 1. Deprecate string exceptions.
>=20
> 2. Make Exception a new-style class.
>=20
> 3. Require exceptions to be derived from Exception.
>=20
> 4. Make the traceback an attribute of the exception object.

You've got point 2 too early; it needs to go after point 3 and posibly
after point 4.
--=20
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.=
com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From aahz@pythoncraft.com  Thu Jun 12 12:36:31 2003
From: aahz@pythoncraft.com (Aahz)
Date: Thu, 12 Jun 2003 07:36:31 -0400
Subject: [Python-Dev] bool() without arguments
In-Reply-To: <200306120302.h5C322U03138@oma.cosc.canterbury.ac.nz>
References: <003d01c32ff6$2dad53a0$59b92c81@oemcomputer> <200306120302.h5C322U03138@oma.cosc.canterbury.ac.nz>
Message-ID: <20030612113631.GB9196@panix.com>

On Thu, Jun 12, 2003, Greg Ewing wrote:
>
>> - bool() called without arguments now returns False rather than
>>   raising an exception.  This is consistent with calling the
>>   constructors for the other builtin types -- called without argument
>>   they all return the false value of that type.  (SF patch #724135)
> 
> That's clearly useful for mutable types such as lists and dicts, but
> for immutable types? Especially one such as bool whose possible values
> are so, er, symmetrical in prominence (is there a succinct word for
> this concept?)
>
> Does anyone have a use case for this?

Generic usage of type constructors?  If yes, that would argue for an
extension of PEP 8.

(Should the error message if people don't agree say something like,
"That's not an argument, that's abuse.")
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From mal@lemburg.com  Thu Jun 12 12:57:07 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 12 Jun 2003 13:57:07 +0200
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: <200306120457.h5C4vn503385@oma.cosc.canterbury.ac.nz>
References: <200306120457.h5C4vn503385@oma.cosc.canterbury.ac.nz>
Message-ID: <3EE86A93.5090504@lemburg.com>

Greg Ewing wrote:
> Tim:
> 
>>[Greg Ewing]
>>
>>>Why on earth would you be trying to instantiate something
>>>without having any idea what parameters are required?
>>
>>For example, unpickling can need to do this when a type uses the
>>__getstate__ + __setstate__ pickle subsystem 
> 
> But that can't possibly work for immutable types.

Right and it's also not really needed since new style classes
provide __new__ and __init__ as two separate entry points.
pickle would have to call __new__ on these and then call
__setstate__ if the protocol is supported by the type.
(At least that's how understand it should work :-)

Given that approach, you don't need to call __init__
at all.

Still waiting for that use case... :-) Otherwise the whole idea
looks too much like a YAGNI if you ask me.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 12 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        12 days left



From barry@python.org  Thu Jun 12 13:41:33 2003
From: barry@python.org (Barry Warsaw)
Date: 12 Jun 2003 08:41:33 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <3EE85983.5040703@livinglogic.de>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
 <3EE85983.5040703@livinglogic.de>
Message-ID: <1055421692.13183.5.camel@anthem>

On Thu, 2003-06-12 at 06:44, Walter D=F6rwald wrote:

> 5. Implement exception chaining (as an attribute named cause on
>     the outer exception referencing the inner exception).

I'm not keen on the name "cause" for the start of the exception chain.
I'm not sure I have a better suggestion.  Maybe "antecedent"? ;/

-Barry



From walter@livinglogic.de  Thu Jun 12 13:49:14 2003
From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Thu, 12 Jun 2003 14:49:14 +0200
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <1055421692.13183.5.camel@anthem>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>	 <3EE85983.5040703@livinglogic.de> <1055421692.13183.5.camel@anthem>
Message-ID: <3EE876CA.3080903@livinglogic.de>

Barry Warsaw wrote:

> On Thu, 2003-06-12 at 06:44, Walter Dörwald wrote:
> 
> 
>>5. Implement exception chaining (as an attribute named cause on
>>    the outer exception referencing the inner exception).
> 
> 
> I'm not keen on the name "cause" for the start of the exception chain.
> I'm not sure I have a better suggestion.  Maybe "antecedent"? ;/

"reason"?

Bye,
    Walter Dörwald




From fdrake@acm.org  Thu Jun 12 13:49:51 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 12 Jun 2003 08:49:51 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <1055421692.13183.5.camel@anthem>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
 <3EE85983.5040703@livinglogic.de>
 <1055421692.13183.5.camel@anthem>
Message-ID: <16104.30447.867524.802799@grendel.zope.com>

Barry Warsaw writes:
 > I'm not keen on the name "cause" for the start of the exception chain.
 > I'm not sure I have a better suggestion.  Maybe "antecedent"? ;/

I actually like "cause" better than "antecedent", though not by a
whole lot.  The SAX exception (SAXException, of course;) provides a
method getException() to retrieve the embedded exception, though I'd
prefer a simple attribute or property.


  -Fred

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


From walter@livinglogic.de  Thu Jun 12 13:51:34 2003
From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Thu, 12 Jun 2003 14:51:34 +0200
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <3EE876CA.3080903@livinglogic.de>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>	 <3EE85983.5040703@livinglogic.de> <1055421692.13183.5.camel@anthem> <3EE876CA.3080903@livinglogic.de>
Message-ID: <3EE87756.1010400@livinglogic.de>

Walter Dörwald wrote:

> Barry Warsaw wrote:
> 
>> On Thu, 2003-06-12 at 06:44, Walter Dörwald wrote:
>>
>>> 5. Implement exception chaining (as an attribute named cause on
>>>    the outer exception referencing the inner exception).
>>
>> I'm not keen on the name "cause" for the start of the exception chain.
>> I'm not sure I have a better suggestion.  Maybe "antecedent"? ;/
> 
> "reason"?

Ouch, this will collide with the PEP 293 exceptions, that already
have an attribute reason.

Bye,
    Walter Dörwald



From ark@research.att.com  Thu Jun 12 13:55:12 2003
From: ark@research.att.com (Andrew Koenig)
Date: 12 Jun 2003 08:55:12 -0400
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135
In-Reply-To: <200306120302.h5C322U03138@oma.cosc.canterbury.ac.nz>
References: <200306120302.h5C322U03138@oma.cosc.canterbury.ac.nz>
Message-ID: <yu99vfvbfob3.fsf@europa.research.att.com>

>> - bool() called without arguments now returns False rather than
>> raising an exception.  This is consistent with calling the
>> constructors for the other builtin types -- called without argument
>> they all return the false value of that type.  (SF patch #724135)

Greg> That's clearly useful for mutable types such as lists
Greg> and dicts, but for immutable types? Especially one such
Greg> as bool whose possible values are so, er, symmetrical
Greg> in prominence (is there a succinct word for this
Greg> concept?)

I think that if T is an unknown type, it would be nice for T() to be
meaningful in a similar way over as many values of T as possible
without special cases.  One possible use might be to write type(x)()
for a canonical value of the same type as x.

-- 
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark


From pje@telecommunity.com  Thu Jun 12 13:55:17 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jun 2003 08:55:17 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <16E1010E4581B049ABC51D4975CEDB88619A98@UKDCX001.uk.int.ato
 sorigin.com>
Message-ID: <5.1.0.14.0.20030612083049.0273edf0@mail.telecommunity.com>

At 11:29 AM 6/12/03 +0100, Moore, Paul wrote:
>From: Moore, Paul
> > Specifically, requirement (e) in the PEP considers precisely
> > the case where neither the "protocol" nor the "object" need
> > to know about the adapt() mechanism. Sadly, the reference
> > implementation provided does not support requirement (e).
>
>And doubly sadly, I see that PyProtocols doesn't either. I'd
>suggest that you add this, and then maybe your "chicken and egg"
>issues will go away. Or maybe I've missed something :-)

Open protocols solve the chicken and egg problem by allowing one to make 
declarations about third-party objects.  The problem with __adapt__ and 
__conform__ is as you say: people have to write things to support 
them.   PyProtocols bootstraps this by providing plenty of objects, base 
classes, adapters, and wrappers that support __adapt__ and __conform__.

While it's true that you can't use 'adapt(ob,file)' meaningfully, there's 
nothing stopping you from saying 'declareImplementation(file,[IFile])' and 
'adapt(ob,IFile)'.  (And the user can say 
'adviseObject(ob,provides=[IFile]) before passing you 'ob'.)  The point of 
the open protocol mechanism is that you can make these declarations 
relative to a specific package's interfaces, *without* requiring there to 
be a common standard.  (Because you can define the relationships between 
different packages' interfaces.)

To put it another way...  it isn't necessary that 'file' be a protocol in 
the Python core.  If I write code that needs a file, I define a protocol 
that means whatever I want it to mean, and if files satisfy that 
requirement, I declare that file satisfies it.  If a user has an object 
that they believe satisfies my requirement, they declare that it does 
(whether they created it or somebody else did).  As long as I use an "open" 
protocol (one that will accept declarations), then this works.

At present, there are only three implementations of open protocols (that 
conform to PyProtocols' API): protocols derived from PyProtocols base type, 
Zope interfaces, and Twisted interfaces.  However, in principle, one could 
use any other interface type that had the ability to be told what objects 
support or adapt to the interface.  To use them with PyProtocols, one would 
need an adapter that translated their current API to the PyProtocols API, 
like the two I wrote for Zope and Twisted.

Anyway, PyProtocols provides enough functionality around PEP 246 to allow a 
great deal of useful development to happen without ever writing an 
__adapt__ or __conform__ method.  So, from my point of view it breaks the 
chicken-and-egg problem because if you write an app using PyProtocols to 
define interfaces and adapt to them, then end users can extend it.  They 
don't have to write __conform__ methods, and you don't have to write 
__adapt__ methods.  You both use the declaration API, unless you need to do 
something that's very unusual indeed.

The declaration API (all the functions named 'declareSomething' or 
'adviseSomething') is the main addition to PEP 246 (aside from some minor 
refinements to the specification of adapt()).  That is where I'm most 
interested in third-party critique, especially from developers of other 
interface systems than the ones I've already written adapters for, and for 
that matter from the Zope and Twisted developers for their perspective on 
whether PyProtocols' architecture would be reusable for them to support 
additional capabilities in their interface types (since PyProtocols 
declaration API is a superset of the declaration facilities provided for 
Zope and Twisted interfaces currently).



From pedronis@bluewin.ch  Thu Jun 12 14:23:12 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Thu, 12 Jun 2003 15:23:12 +0200
Subject: [Python-Dev] Caching of builtins and globals
Message-ID: <5.2.1.1.0.20030612134607.00a6c8b0@pop.bluewin.ch>

I have played a bit with the notion of caching builtin and global values 
(to be precise the address of their dictionary entry) without changing 
language semantics:

I have an experimental modification to the interpreteter such that I get 
these numbers: [bl_ is the baseline CVS code, ex_ is the modified interpreter]:

$ ./bl_python test.py
nop func
5.26905059814  ms
5.17392158508  ms
5.10895252228  ms
all-locals func
3537.45496273  ms
3536.81099415  ms
3537.69803047  ms
global/builtin-heavy func
4377.18105316  ms
4378.40998173  ms
4375.61702728  ms
sup ctr
57391.8089867  ms
57239.0290499  ms
57295.1930761  ms
$ ./ex_python test.py
nop func
5.01906871796  ms
5.34105300903  ms
5.30099868774  ms
all-locals func
3505.41305542  ms
3529.50799465  ms
3529.50108051  ms
global/builtin-heavy func
3750.57899952  ms
3752.10404396  ms
3725.95608234  ms
sup ctr
47528.2179117  ms
47529.8720598  ms
47295.0160503  ms
$

for

<test.py>
R=3
N = 5000
M = 1000
import time
ch = 'T'

def bot():
     pass
class d(dict):
     def __init__(self):
        dict.__init__(self,{1:1})
def f():
     ord_ = ord
     ch_ = ch
     x = 0
     for i in range(M):
         x += ord_(ch_)
def g():
     x = 0
     for i in range(M):
         x += ord(ch)
def h():
     dic = None
     for i in range(M):
         dic = d()
def test(func,n):
     t = time.time()
     for i in xrange(N):
         func()
     print (time.time()-t)*1000, ' ms'

print "nop func"
for i in range(R):
     test(bot,N)
print "all-locals func"
for i in range(R):
     test(f,N)
print "global/builtin-heavy func"
for i in range(R):
     test(g,N)
print "sup ctr"
for i in range(R):
     test(h,100)
</test.py>

[AMD Athlon 750Mhz under RH Linux 7.2, pystone seems to get 4/5% 
improvements, neverthelss I expect slowdowns in some cases]

idea/issues:
- the most "evil" thing I do is add a further pointer to all dicts to store 
what I call a version token. Reshaping* mutation paths for dicts grow code 
for updating the version token, this is executed conditionally only if the 
version token pointer is non-null, i.e. the version token was asked at 
least once and so one was put in place. So mutation for normal dicts (not 
used as globals/builtins) pay only to skip the code with a 
check-non-null-jump. [version tokens are small objects with their own ref 
counting logic, their are not version counters for reasons related to 
overflow and so that they capture also the identity of their dicts:
	dic1 != dic2 => dic1.version != dic2.version ].
Using different dict kinds could avoid the all-pay problem. This is slowed 
down:

import mod
mod.foo = 1

if 'foo' doesn't already exist in mod because a new version token must be 
generated.

[*: empty entry to non-empty, the converse, and things that change 
key->entry (address) mapping (e.g. resizing)]

- I didn't touch the compiler/bytecode. I allocate caches with 
len(co_names) entries. LOAD_GLOBAL args run over [0,len(co_names)[.

- the basic invariant is that as long as the version tokens of a pair of 
globals/builtins dicts is unchanged, a LOAD_GLOBAL would retrieve its value 
*at the same* dict entry address. So the LOAD_GLOBAL fast-path becomes:

		case LOAD_GLOBAL:
			if (((PyDictObject *)f->f_globals)->version == glover &&
			    ((PyDictObject *)f->f_builtins)->version == bltver) {
				if(glocache[oparg]) {
					TRC_GLOCACHE("using cache\n");
					x = glocache[oparg]->me_value;
					Py_INCREF(x);
					PUSH(x);
					continue;
				}
			} else

- caches are wrapped in CObjects (quick hack) to get proper collection. 
They are stored and shared through code objects together with the 
globals/builtins version tokens they correspond to. The invariant and that 
a cache is *only* used for a given pair of version tokens, should guarantee 
that sharing is fine. If the versions tokens change during the run of some 
code a new fresh cache is created and used. The assumptions is that this is 
rare after "startup" phase.
Code that pay a price are e.g. modules that in their top-level setup some 
globals, call a function, add some more globals, recall the function... 
because each function call will create and start populating  a new fresh cache.

- although I have tried to trigger DECREFs (that could run arbitrary code) 
only from consistent state, that's a delicate aspect. Similar is the 
problem to have version tokens timely updated.

- ceval switch is indeed an unwieldy beast. For sure I did'nt manage (nor 
really tried) to find the best code layout with respect to cpu cache/code 
generation. The problem is that slowdowns for not-fast-paths (and sadly 
even unrelated stuff) depend on this.

It's a two day work (& my C is a bit rusty) so some bug/issues could be 
lurking, OTOH the test suite passes. I have no more time to further play 
with this, is not really in general consumption shape but if someone is 
interested I can post the diff (is less than 1000 lines together with context).

regards. 



From guido@python.org  Thu Jun 12 14:27:59 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 09:27:59 -0400
Subject: [Python-Dev] Patch to remove eval from csv sniffer
In-Reply-To: Your message of "Thu, 12 Jun 2003 12:05:03 +1000."
 <20030612020503.5D8DD3C41B@coffee.object-craft.com.au>
References: <20030612020503.5D8DD3C41B@coffee.object-craft.com.au>
Message-ID: <200306121328.h5CDRxT11057@odiug.zope.com>

> The patch by Raymond Hettinger mentioned here:
> 
>     www.python.org/sf/744104
> 
> makes a lot of sense. The question is - should it be applied now? We're
> in the 55th minute of the 11th hour for 2.3, and changes are generally
> unwelcome. This change changes the sniffer's behaviour slightly, but
> it's probably better to do this now, than after 2.3 is released (and
> it's a potential security problem).

Better now.

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


From gtalvola@nameconnector.com  Thu Jun 12 14:40:59 2003
From: gtalvola@nameconnector.com (Geoffrey Talvola)
Date: Thu, 12 Jun 2003 09:40:59 -0400
Subject: [Python-Dev] Two useful patches involving tracebacks
Message-ID: <61957B071FF421419E567A28A45C7FE59AF4C5@mailbox.nameconnector.com>

The first one is a no-brainer bugfix that helps users of COM on Windows.
The second one has some question as to whether it's the correct
implementation, but I can vouch that if nothing else, it's incredibly useful
and I haven't had any problems with it.

[ 672855 ] improve pydoc handling of extension types
http://sourceforge.net/tracker/index.php?func=detail&aid=672855&group_id=547
0&atid=305470

[ 569574 ] plain text enhancement for cgitb
http://sourceforge.net/tracker/index.php?func=detail&aid=569574&group_id=547
0&atid=305470

I'm calling attention to these patches simply because I've found them to be
so useful, and it would be a shame to see them not make it into 2.3 beta 2
simply due to lack of attention.  If it helps, I'm willing to do the
checkins if I'm granted CVS write access :-)

- Geoff


From andrewm@object-craft.com.au  Thu Jun 12 14:41:58 2003
From: andrewm@object-craft.com.au (Andrew McNamara)
Date: Thu, 12 Jun 2003 23:41:58 +1000
Subject: [Python-Dev] Patch to remove eval from csv sniffer
In-Reply-To: Message from Guido van Rossum <guido@python.org>
 of "Thu, 12 Jun 2003 09:27:59 -0400." <200306121328.h5CDRxT11057@odiug.zope.com>
References: <20030612020503.5D8DD3C41B@coffee.object-craft.com.au>  <200306121328.h5CDRxT11057@odiug.zope.com>
Message-ID: <20030612134158.7522B3C421@coffee.object-craft.com.au>

>> The patch by Raymond Hettinger mentioned here:
>> 
>>     www.python.org/sf/744104
>> 
>> makes a lot of sense. The question is - should it be applied now? We're
>> in the 55th minute of the 11th hour for 2.3, and changes are generally
>> unwelcome. This change changes the sniffer's behaviour slightly, but
>> it's probably better to do this now, than after 2.3 is released (and
>> it's a potential security problem).

Guido said:
>Better now.

Raymond has commited it. Ta.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/


From guido@python.org  Thu Jun 12 14:44:30 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 09:44:30 -0400
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: Your message of "Thu, 12 Jun 2003 16:12:26 +1200."
 <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz>
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz>
Message-ID: <200306121344.h5CDiUi11167@odiug.zope.com>

> > Types with constructors that insist on an argument are problematic to
> > generic code that tries to instantiate a type by simply calling it.
> 
> Why on earth would you be trying to instantiate something
> without having any idea what parameters are required?

It could be the other way though: something could have a protocol
where you can pass in a factory function that's called without
arguments, and maybe you'd like to be able to pass it a built-in
type.  Something very close to this happened to me when testing Zope 3
filesystem synchronization.

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



From guido@python.org  Thu Jun 12 14:48:37 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 09:48:37 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: Your message of "Thu, 12 Jun 2003 16:28:59 +1200."
 <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
Message-ID: <200306121348.h5CDmbH11196@odiug.zope.com>

> > More globals of course defeat the purpose (one of the reasons for
> > putting the traceback in the exception is to get rid of
> > sys.exc_traceback).
> 
> I think the idea was that this would be a C-level global,
> not a Python one (i.e. part of the existing group of
> C variables representing the current exception state).

Possibly, except those aren't globals either (they're members of the
per-thread state record).

> > I also think that doing this automatically whenever PyErr_Set*() is
> > called would cause a lot of spurious tracebacks.  (Unless the idea is
> > to skip the chaining if the original exception has an empty
> > traceback
> 
> I don't understand that. What is a "spurious" traceback? And how
> are you going to get one if the current traceback is empty?

I was imagining that the default mechanism for printing tracebacks
would always try to follow the chain of tracebacks, and report not
just the traceback, but also the exception that was replaced.  There's
a lot of C code out there that catches e.g. AttributeError and
replaces it with a more specific error (e.g. BifurcationError("can't
bifurcate the sploorg") replacing AttributeError("__bifurcate__").
I think this would cause end user confusion.

> > I worry about backwards compatibility.
> 
> What would this break? Code which doesn't know about chained
> exceptions can just ignore the new attribute and get exactly
> the information they used to get from the exception and its
> traceback, as far as I can see.

I didn't mean code breakage, but the above change in output.

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


From barry@python.org  Thu Jun 12 15:26:44 2003
From: barry@python.org (Barry Warsaw)
Date: 12 Jun 2003 10:26:44 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <16104.30447.867524.802799@grendel.zope.com>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
 <3EE85983.5040703@livinglogic.de> <1055421692.13183.5.camel@anthem>
 <16104.30447.867524.802799@grendel.zope.com>
Message-ID: <1055428004.4982.4.camel@barry>

On Thu, 2003-06-12 at 08:49, Fred L. Drake, Jr. wrote:

> I actually like "cause" better than "antecedent", though not by a
> whole lot.  The SAX exception (SAXException, of course;) provides a
> method getException() to retrieve the embedded exception, though I'd
> prefer a simple attribute or property.

Me too, but "cause" implies (to me) a stronger connection between the
original exception and the one you've just caught.  More suggestions,
none great: "original", "chain", "chainedexc", "exc_chain", "excprev",
"previous".

-Barry




From Paul.Moore@atosorigin.com  Thu Jun 12 15:42:41 2003
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu, 12 Jun 2003 15:42:41 +0100
Subject: [Python-Dev] PEP 246 and Protocols (Was: Sneaky 'super' instances)
Message-ID: <16E1010E4581B049ABC51D4975CEDB88619A99@UKDCX001.uk.int.atosorigin.com>

From: Phillip J. Eby [mailto:pje@telecommunity.com]
> Open protocols solve the chicken and egg problem by allowing one
> to make declarations about third-party objects.

Um....... This isn't a criticism per se, but my eyes glaze over when I
see stuff like this. I know it's not, but it reads like marketing, and
I end up not being able to follow the real point. It's my problem, not
yours, but I mention it in case I seem to fail to get the point...

[time passes]

OK, I've tried to put together a simple example of "what I expect" and
I find I can't. I want to continue to write code which "just assumes"
that it gets the types it needs - I don't want to explicitly state that
I need specific interface types - that feels like type declaration and
Java. Your IFile example reinforces that, both in terms of its naming
convention, and in the assumption that there *is* a single, usable,
"file" protocol. I know it was my example, but I pointed out later in
the same message that I really sometimes wanted seekable readline-only
files, and other times block read/write (potentially unseekable) files.

Expecting library writers to declare interface "classes" for every
subtle variation of requirements seems impractical. Expecting the
requirements to be *documented* is fine - it's having a concrete class
which encapsulates them that I don't see happening - no-one would ever
look to see if there was already a "standard" interface which said "I
have readline, seek, and tell" - they'd just write a new one. There
goes any hope of reuse. (This may be what you see as a "chicken and egg"
problem - if so, I see it as a "hopelessly unrealistic expectations"
problem instead, because it's never going to happen...)

On the other hand, expecting callers to write stuff to adapt existing
classes to the requirements of library routines is (IMHO) a non-issue.
I think that's what PEP 246 was getting at in the statement that "The
typical Python programmer is an integrator" which you quote. It's
common to write

    class wrap_source:
        def __init__(self, source):
            self.source =3D source
        def read(self, n =3D 1024):
            return self.source.get_data(n)

    lib_fn(wrap_source(my_source))

So PEP 246 is trying to make writing that sort of boilerplate easier
(in my view). The *caller* should be calling adapt(), not the callee.

On that basis, adapt(obj, file) could be a fluid notion, depending on
what the caller has "registered" as an adapter for a file object. In
a situation where he is only calling library routines which need
readable files, adapt(obj, file) may completely omit write methods. In
another context that may be a disaster. The called routines still have
expectations, and it's the caller's responsibility to respect them. But
adapt() offers a general facility to help the caller avoid writing
boilerplate classes like the above.

In this context, __adapt__ allows class writers to build compatibility
wrappers using a common framework. For example, StringIO could be
replaced by an __adapt__ method of the file class:

    class file: # OK, it's just a demo...
        def __adapt__(self, obj):
            if isinstance(obj, basestring):
                return StringIO.StringIO(obj)

Then code which wants to pass a string to a function which expects a
file could do

    process(adapt(my_string, file))

And conversely, __conform__ does the same for the writer of the string
class:

    class string:
        def __conform__(self, type):
            if type is file:
                return StringIO.StringIO(self)

Which is appropriate is basically down to which came first, string or
file. But both suffer from the problem of putting all the knowledge
in one location (and using a type switch as well).

The third option, which is the "external registry" allows a *user* of
the string and file "libraries" (bear with me here...) to say how he
wants to make strings look like files:

    import pep246
    import StringIO

    def str_to_file(str):
        return StringIO.StringIO(str)

    # Note that this effectively uses multiple dispatch
    # somewhere in there...
    pep246.register(basestring, file, str_to_file)

    # And now adapt(my_string, file) does what we want!

So I see PEP 246 as more or less entirely a class based mechanism. It
has very little to do with constraining (or even documenting) the
types of function parameters.

Of course, a library writer can define interface classes, and the
adaptation mechanism will allow concrete classes to be made to
"conform" to those interfaces, but it's not necessary. And given
the general apathy of the Python community towards interfaces (at
least as far as I see) I don't imagine this being a very popular use
pattern. And describing a PEP 246 style facility in terms of
interfaces could be a big turn-off. (This applies strongly to your
PyProtocols code - I looked for something like the pep246.register
function I suggested above, but I couldn't manage to wade through all
the IThis and IThat stuff to find it, if it was there...)

Once again, I apologise if I've missed your point. But I hope I've
explained what I see as the point of PEP 246, and where your proposal
is going off in a different direction.

But the fact remains, that neither PEP 246 nor PyProtocols has any
need to be in the core, or even in the standard library (yet). Wide
usage could change that. Usage in something that is destined for the
standard library could, too, but that one could go the other way (the
"something" gets rejected because it depends on PEP246/PyProtocols).
I believe that dependency on PEP 246 would be less of a barrier here
than dependency on PyProtocols. But don't assume that just because
I'm writing long messages that my opinion carries any weight :-)

Paul.

PS This is *way* off-topic for python-dev by now. I suggest that we
   leave things here. I don't have anything else worth adding...


From walter@livinglogic.de  Thu Jun 12 15:55:23 2003
From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Thu, 12 Jun 2003 16:55:23 +0200
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121348.h5CDmbH11196@odiug.zope.com>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz> <200306121348.h5CDmbH11196@odiug.zope.com>
Message-ID: <3EE8945B.2040502@livinglogic.de>

Guido van Rossum wrote:

> [...]
>>I don't understand that. What is a "spurious" traceback? And how
>>are you going to get one if the current traceback is empty?
> 
> I was imagining that the default mechanism for printing tracebacks
> would always try to follow the chain of tracebacks, and report not
> just the traceback, but also the exception that was replaced.  There's
> a lot of C code out there that catches e.g. AttributeError and
> replaces it with a more specific error (e.g. BifurcationError("can't
> bifurcate the sploorg") replacing AttributeError("__bifurcate__").
> I think this would cause end user confusion.

Isn't the new sys.exc_clear() usable for that? (I.e. raising
a fresh exception without any chained ones?)

> [...]

Bye,
    Walter Dörwald




From guido@python.org  Thu Jun 12 15:56:33 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 10:56:33 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: Your message of "Thu, 12 Jun 2003 12:44:19 +0200."
 <3EE85983.5040703@livinglogic.de>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
 <3EE85983.5040703@livinglogic.de>
Message-ID: <200306121456.h5CEuYx11521@odiug.zope.com>

> So maybe the plan should look somethink like this:
> 
> 1. Deprecate string exceptions.
> 
> 2. Make Exception a new-style class.
> 
> 3. Require exceptions to be derived from Exception.
> 
> 4. Make the traceback an attribute of the exception object.
> 
> 5. Implement exception chaining (as an attribute named cause on
>     the outer exception referencing the inner exception).
> 
> 6. Add other exception attributes (e.g. KeyError has an attribute
>     key, IndexError has an attribute index, IOError has attributes
>     filename, errorcode etc.)

I think (1) and (3) aren't absolutely necessary -- strings and classic
classes would simply not have the traceback attribute.  For backwards
compatibility it could still be kept separate in (the per-thread
equivalent of) sys.exc_traceback, but at some point, that would be
phased out and traceback reporting for deprecated exception types
would be reduced -- a nice incentive for moving to new-style
exceptions!  (Or, for classic classes, it wouldn't be okay to store
the traceback on a system attribute, e.g. __traceback__.)

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


From fincher.8@osu.edu  Thu Jun 12 17:01:08 2003
From: fincher.8@osu.edu (Jeremy Fincher)
Date: Thu, 12 Jun 2003 12:01:08 -0400
Subject: [Python-Dev] Two useful patches involving tracebacks
In-Reply-To: <61957B071FF421419E567A28A45C7FE59AF4C5@mailbox.nameconnector.com>
References: <61957B071FF421419E567A28A45C7FE59AF4C5@mailbox.nameconnector.com>
Message-ID: <200306121201.08930.fincher.8@osu.edu>

On Thursday 12 June 2003 09:40 am, Geoffrey Talvola wrote:
> [ 569574 ] plain text enhancement for cgitb
> http://sourceforge.net/tracker/index.php?func=detail&aid=569574&group_id=54
>7 0&atid=305470

I'll second that I find this patch very useful; I've been using it in my own 
cgitb.py for some time.

Jeremy


From fdrake@acm.org  Thu Jun 12 16:02:46 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 12 Jun 2003 11:02:46 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121456.h5CEuYx11521@odiug.zope.com>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz>
 <3EE85983.5040703@livinglogic.de>
 <200306121456.h5CEuYx11521@odiug.zope.com>
Message-ID: <16104.38422.195193.672399@grendel.zope.com>

Guido van Rossum writes:
 > exceptions!  (Or, for classic classes, it wouldn't be okay to store
 > the traceback on a system attribute, e.g. __traceback__.)

I don't know that I've heard you use the term "system attribute"
before -- I like it!


  -Fred

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


From guido@python.org  Thu Jun 12 16:11:18 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 11:11:18 -0400
Subject: [Python-Dev] Two useful patches involving tracebacks
In-Reply-To: Your message of "Thu, 12 Jun 2003 09:40:59 EDT."
 <61957B071FF421419E567A28A45C7FE59AF4C5@mailbox.nameconnector.com>
References: <61957B071FF421419E567A28A45C7FE59AF4C5@mailbox.nameconnector.com>
Message-ID: <200306121511.h5CFBIC11672@odiug.zope.com>

> The first one is a no-brainer bugfix that helps users of COM on
> Windows.  The second one has some question as to whether it's the
> correct implementation, but I can vouch that if nothing else, it's
> incredibly useful and I haven't had any problems with it.
> 
> [ 672855 ] improve pydoc handling of extension types
> http://sourceforge.net/tracker/index.php?func=detail&aid=672855&group_id=5470&atid=305470
> 
> [ 569574 ] plain text enhancement for cgitb
> http://sourceforge.net/tracker/index.php?func=detail&aid=569574&group_id=5470&atid=305470
> 
> I'm calling attention to these patches simply because I've found
> them to be so useful, and it would be a shame to see them not make
> it into 2.3 beta 2 simply due to lack of attention.  If it helps,
> I'm willing to do the checkins if I'm granted CVS write access :-)

I'll add my usual disclaimer that I haven't had time to review these,
but the proposed functionality certainly makes sense to add.

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


From guido@python.org  Thu Jun 12 16:22:39 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 11:22:39 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: Your message of "Thu, 12 Jun 2003 16:55:23 +0200."
 <3EE8945B.2040502@livinglogic.de>
References: <200306120428.h5C4SxF03299@oma.cosc.canterbury.ac.nz> <200306121348.h5CDmbH11196@odiug.zope.com>
 <3EE8945B.2040502@livinglogic.de>
Message-ID: <200306121522.h5CFMdk11799@odiug.zope.com>

> > [...]
> >>I don't understand that. What is a "spurious" traceback? And how
> >>are you going to get one if the current traceback is empty?
> > 
> > I was imagining that the default mechanism for printing tracebacks
> > would always try to follow the chain of tracebacks, and report not
> > just the traceback, but also the exception that was replaced.  There's
> > a lot of C code out there that catches e.g. AttributeError and
> > replaces it with a more specific error (e.g. BifurcationError("can't
> > bifurcate the sploorg") replacing AttributeError("__bifurcate__").
> > I think this would cause end user confusion.
> 
> Isn't the new sys.exc_clear() usable for that? (I.e. raising
> a fresh exception without any chained ones?)

But that's backwards incompatible, in the sense that currently you
don't need to call exc_clear() unless under very special
circumstances.

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



From pedronis@bluewin.ch  Thu Jun 12 16:35:41 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Thu, 12 Jun 2003 17:35:41 +0200
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <5.1.0.14.0.20030612083049.0273edf0@mail.telecommunity.com>
References: <16E1010E4581B049ABC51D4975CEDB88619A98@UKDCX001.uk.int.ato sorigin.com>
Message-ID: <5.2.1.1.0.20030612165145.024772b8@pop.bluewin.ch>

At 08:55 12.06.2003 -0400, Phillip J. Eby wrote:
>While it's true that you can't use 'adapt(ob,file)' meaningfully, there's 
>nothing stopping you from saying 'declareImplementation(file,[IFile])' and 
>'adapt(ob,IFile)'.  (And the user can say 
>'adviseObject(ob,provides=[IFile]) before passing you 'ob'.)  The point of 
>the open protocol mechanism is that you can make these declarations 
>relative to a specific package's interfaces, *without* requiring there to 
>be a common standard.  (Because you can define the relationships between 
>different packages' interfaces.)

The problem is that especially in the context of the std library or simple 
Python usage vs. complex frameworks and apps or software engineering heavy 
situations in general, what I would call micro protocol are quite often used:

if IFile means to have all the methods of file is probably too much, and 
even if there are adpaters that can complete very partial implementations. 
For really general adoption even asking people to declare things for quick 
scripts is too much.

Consider this fragment:

   if hasattr(obj,'read'):
       ... use obj.read ...
   elif if hasattr(obj,'value'):
       ...

if I want to rewrite it using adapt:

aobj = adapt(obj,?)

so? IFile is too much, inventing names for all micro subsets of IFile seems 
also rather problematic. Especially considering the client situation:

import ...protocol stuff... # boilerplate

class MyObj:

   def read():
     ...

declareImplementation(MyObj,[?]) # boilerplate

So we have the conflicting needs of libraries that want to use and support 
adaptation even for micro-protocols and provide the gained flexibility and 
of  users that want to use them (the std lib could be such a lib) for quick 
scripts, and hate boilerplate. And we have the taxonomy issue.

Once I already sketched in a mail to the list a possible solution to this 
problem. I have read a bit PyProtocols documentation and I think that my 
idea is probably implementatble on top of PyProtocols.

The idea is to allow for anonymous subsetting of protocols:

subproto(IFile,'read'[,...])

there would be a cache to guarantee uniqueness of these things.
Given that in

subproto(Protocol, method-names)

len(method-names) would be small (<5), even if there exponatial many 
subsets of method-names :) it should be tractable to automatically register 
all the natural relationships:
subproto(IFile,'read','write') > subproto(IFile,'read')

Obviously these anonymous sub-protocols would be instantiated on demand, 
not when IFile is created.

The final point then is that there should be a [global?] flag to choose 
between strict or loose checking for this protocols:

ReadProto=subproto(IFile,'read')

aobj = adapt(obj,ReadProto)

in loose mode obj would directly adapt to ReadProto if it has a 'read' 
attribute.
In strict mode some adaption path should have been registered explicitly: e.g.:

class MyObj:

   def read():
     ...

declareImplementation(MyObj,[subproto(IFile,'read')])

regards. 



From skip@pobox.com  Thu Jun 12 16:42:52 2003
From: skip@pobox.com (Skip Montanaro)
Date: Thu, 12 Jun 2003 10:42:52 -0500
Subject: [Python-Dev] Two useful patches involving tracebacks
In-Reply-To: <200306121511.h5CFBIC11672@odiug.zope.com>
References: <61957B071FF421419E567A28A45C7FE59AF4C5@mailbox.nameconnector.com>
 <200306121511.h5CFBIC11672@odiug.zope.com>
Message-ID: <16104.40828.6195.399040@montanaro.dyndns.org>

    ...
    >> [ 569574 ] plain text enhancement for cgitb
    >> http://sourceforge.net/tracker/index.php?func=detail&aid=569574&group_id=5470&atid=305470

    Guido> I'll add my usual disclaimer that I haven't had time to review
    Guido> these, but the proposed functionality certainly makes sense to
    Guido> add.

There was a little discussion about the cgitb patch when I first submitted
it.  The problem isn't so much that it does anything wrong, it's that it
suggests the traceback and cgitb modules should probably be refactored.
Much of what cgitb does probably belongs in the traceback module, with an
HTML report generator in cgitb and a plain text report generator elsewhere
(perhaps in traceback).

At any rate, if someone else would look at it and pronounce, I'd be happy to
check it in.  The enhanced plain text tracebacks should be extremely helpful
when analyzing tracebacks from long-running processes where you can't simply
throw in a couple prints and re-run the program.

Skip



From Anthony Baxter <anthony@interlink.com.au>  Thu Jun 12 17:02:50 2003
From: Anthony Baxter <anthony@interlink.com.au> (Anthony Baxter)
Date: Fri, 13 Jun 2003 02:02:50 +1000
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121456.h5CEuYx11521@odiug.zope.com>
Message-ID: <200306121602.h5CG2o712460@localhost.localdomain>

>>> Guido van Rossum wrote
> I think (1) and (3) aren't absolutely necessary -- strings and classic
> classes would simply not have the traceback attribute.  For backwards
> compatibility it could still be kept separate in (the per-thread
> equivalent of) sys.exc_traceback, 

As an aside, is it planned that sys.exc_traceback,type and value will
start emitting DeprecationWarnings any time soon? I find myself stumbling 
over them in other people's code far too often for comfort, where they 
are obviously unaware that they're not thread-safe. 

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



From pje@telecommunity.com  Thu Jun 12 17:11:37 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jun 2003 12:11:37 -0400
Subject: [Python-Dev] Sneaky 'super' instances
In-Reply-To: <5.2.1.1.0.20030612165145.024772b8@pop.bluewin.ch>
References: <5.1.0.14.0.20030612083049.0273edf0@mail.telecommunity.com>
 <16E1010E4581B049ABC51D4975CEDB88619A98@UKDCX001.uk.int.ato sorigin.com>
Message-ID: <5.1.1.6.0.20030612115928.026179c0@telecommunity.com>

At 05:35 PM 6/12/03 +0200, Samuele Pedroni wrote:
>Once I already sketched in a mail to the list a possible solution to this 
>problem. I have read a bit PyProtocols documentation and I think that my 
>idea is probably implementatble on top of PyProtocols.
>
>The idea is to allow for anonymous subsetting of protocols:
>
>subproto(IFile,'read'[,...])
>
>there would be a cache to guarantee uniqueness of these things.
>Given that in
>
>subproto(Protocol, method-names)
>
>len(method-names) would be small (<5), even if there exponatial many 
>subsets of method-names :) it should be tractable to automatically 
>register all the natural relationships:
>subproto(IFile,'read','write') > subproto(IFile,'read')
>
>Obviously these anonymous sub-protocols would be instantiated on demand, 
>not when IFile is created.

Hmmm...  this is *very* interesting.  You're right, it *could* be 
implemented on top of the existing PyProtocols.


>The final point then is that there should be a [global?] flag to choose 
>between strict or loose checking for this protocols:
>
>ReadProto=subproto(IFile,'read')
>
>aobj = adapt(obj,ReadProto)
>
>in loose mode obj would directly adapt to ReadProto if it has a 'read' 
>attribute.
>In strict mode some adaption path should have been registered explicitly: 
>e.g.:
>
>class MyObj:
>
>   def read():
>     ...
>
>declareImplementation(MyObj,[subproto(IFile,'read')])

I think this could be done by giving the 'subproto' a "loose" version.  The 
strict version would imply the loose version, but not vice versa.

There are some mechanics to work out for how the cache would work (from a 
reference retaining perspective).  But this seems like a nice sample to add 
to the docs: a 'LooseSubset' Protocol subclass whose __adapt__ can do this 
kind of checking.  Or maybe I should add a complete implementation to the 
next release.  I've been similarly thinking about adding other demo 
protocol types like parameterized protocols (e.g. 
'SequenceOf(otherProtocol)' or 'MappingOf(keys=keyKind,values=valueKind)').

Thank you very much for the idea!



From guido@python.org  Thu Jun 12 17:18:56 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 12:18:56 -0400
Subject: [Python-Dev] Two useful patches involving tracebacks
In-Reply-To: Your message of "Thu, 12 Jun 2003 10:42:52 CDT."
 <16104.40828.6195.399040@montanaro.dyndns.org>
References: <61957B071FF421419E567A28A45C7FE59AF4C5@mailbox.nameconnector.com> <200306121511.h5CFBIC11672@odiug.zope.com>
 <16104.40828.6195.399040@montanaro.dyndns.org>
Message-ID: <200306121618.h5CGIuH11979@odiug.zope.com>

>     >> [ 569574 ] plain text enhancement for cgitb
>     >> http://sourceforge.net/tracker/index.php?func=detail&aid=569574&group_id=5470&atid=305470
> 
>     Guido> I'll add my usual disclaimer that I haven't had time to
>     Guido> review these, but the proposed functionality certainly
>     Guido> makes sense to add.
> 
> There was a little discussion about the cgitb patch when I first
> submitted it.  The problem isn't so much that it does anything
> wrong, it's that it suggests the traceback and cgitb modules should
> probably be refactored.  Much of what cgitb does probably belongs in
> the traceback module, with an HTML report generator in cgitb and a
> plain text report generator elsewhere (perhaps in traceback).
> 
> At any rate, if someone else would look at it and pronounce, I'd be
> happy to check it in.  The enhanced plain text tracebacks should be
> extremely helpful when analyzing tracebacks from long-running
> processes where you can't simply throw in a couple prints and re-run
> the program.

Sad though it is, a major refactoring would be a higher risk than just
checking in the changes now.  Maybe the refactoring can be planned for
2.4.

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


From guido@python.org  Thu Jun 12 17:21:49 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 12:21:49 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: Your message of "Fri, 13 Jun 2003 02:02:50 +1000."
 <200306121602.h5CG2o712460@localhost.localdomain>
References: <200306121602.h5CG2o712460@localhost.localdomain>
Message-ID: <200306121621.h5CGLnq12007@odiug.zope.com>

> As an aside, is it planned that sys.exc_traceback,type and value
> will start emitting DeprecationWarnings any time soon? I find myself
> stumbling over them in other people's code far too often for
> comfort, where they are obviously unaware that they're not
> thread-safe.

It's hard to put a deprecation warning on these, because they're just
module attributes.

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


From guido@python.org  Thu Jun 12 17:26:17 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 12:26:17 -0400
Subject: [Python-Dev] Proposal to drop f_tstate
In-Reply-To: Your message of "Thu, 12 Jun 2003 04:25:47 +0200."
 <3EE7E4AB.8030909@tismer.com>
References: <3EE7E4AB.8030909@tismer.com>
Message-ID: <200306121626.h5CGQHZ12068@odiug.zope.com>

> For years, there has been a f_tstate field in frames.
> 
> During my implementation of thread pickling for Stackless,
> I investigated how much use is made of this field.
> I found out that it is only used in rare cases, only, and can
> be most probably replaced by PyThreadState_GET() in the
> six or seven cases where it is touched at all.
> 
> f_tstate would make sense if PyThreadState_GET() wasn't
> such a cheap macro. It also would make sense if it were used
> somewhere to assure proper allocation of a frame to its tstate.
> But this is nowhere used.
> In the case of Stackless, f_tstate turns out to be even a
> drawback, since non-recursively called frames can be freely
> moved between real threads, and I'm saving updates to f_tstate
> already, simply by removing it.
> 
> I also didn't find any external module that uses f_tstate.
> 
> Therefore, I hereby propose to remove this frame field,
> in order to save space.
> 
> I also offer to provide the simple patch, right now.

I notice that all the places that use f_tstate are functions that get
a frame passed in.  What makes you believe that those always run in
the same thread where the frame was created?

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


From skip@pobox.com  Thu Jun 12 17:28:38 2003
From: skip@pobox.com (Skip Montanaro)
Date: Thu, 12 Jun 2003 11:28:38 -0500
Subject: [Python-Dev] Two useful patches involving tracebacks
In-Reply-To: <200306121618.h5CGIuH11979@odiug.zope.com>
References: <61957B071FF421419E567A28A45C7FE59AF4C5@mailbox.nameconnector.com>
 <200306121511.h5CFBIC11672@odiug.zope.com>
 <16104.40828.6195.399040@montanaro.dyndns.org>
 <200306121618.h5CGIuH11979@odiug.zope.com>
Message-ID: <16104.43574.542191.990526@montanaro.dyndns.org>

    >> There was a little discussion about the cgitb patch when I first
    >> submitted it.  The problem isn't so much that it does anything wrong,
    >> it's that it suggests the traceback and cgitb modules should probably
    >> be refactored....

    Guido> Sad though it is, a major refactoring would be a higher risk than
    Guido> just checking in the changes now.  Maybe the refactoring can be
    Guido> planned for 2.4.

Sure, that would be fine with me.

Skip


From tismer@tismer.com  Thu Jun 12 17:50:25 2003
From: tismer@tismer.com (Christian Tismer)
Date: Thu, 12 Jun 2003 18:50:25 +0200
Subject: [Python-Dev] Proposal to drop f_tstate
In-Reply-To: <200306121626.h5CGQHZ12068@odiug.zope.com>
References: <3EE7E4AB.8030909@tismer.com> <200306121626.h5CGQHZ12068@odiug.zope.com>
Message-ID: <3EE8AF51.1040507@tismer.com>

Guido van Rossum wrote:

...

>>Therefore, I hereby propose to remove this frame field,
>>in order to save space.
...

> I notice that all the places that use f_tstate are functions that get
> a frame passed in.  What makes you believe that those always run in
> the same thread where the frame was created?

Schluck!
I assumed that f_tstate was just some cache, and one would
never try to look into a different thread.
This was a wrong assumption.
Sorry, I will und my changes, ASAP.

thanks - chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



From pje@telecommunity.com  Thu Jun 12 17:48:51 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jun 2003 12:48:51 -0400
Subject: [Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky 'super' instances)
In-Reply-To: <16E1010E4581B049ABC51D4975CEDB88619A99@UKDCX001.uk.int.ato
 sorigin.com>
Message-ID: <5.1.1.6.0.20030612115854.0260e100@telecommunity.com>

At 03:42 PM 6/12/03 +0100, Moore, Paul wrote:
>From: Phillip J. Eby [mailto:pje@telecommunity.com]
> > Open protocols solve the chicken and egg problem by allowing one
> > to make declarations about third-party objects.
>
>OK, I've tried to put together a simple example of "what I expect" and
>I find I can't. I want to continue to write code which "just assumes"
>that it gets the types it needs - I don't want to explicitly state that
>I need specific interface types - that feels like type declaration and
>Java. Your IFile example reinforces that, both in terms of its naming
>convention, and in the assumption that there *is* a single, usable,
>"file" protocol. I know it was my example, but I pointed out later in
>the same message that I really sometimes wanted seekable readline-only
>files, and other times block read/write (potentially unseekable) files.
>
>Expecting library writers to declare interface "classes" for every
>subtle variation of requirements seems impractical. Expecting the
>requirements to be *documented* is fine - it's having a concrete class
>which encapsulates them that I don't see happening - no-one would ever
>look to see if there was already a "standard" interface which said "I
>have readline, seek, and tell" - they'd just write a new one. There
>goes any hope of reuse. (This may be what you see as a "chicken and egg"
>problem - if so, I see it as a "hopelessly unrealistic expectations"
>problem instead, because it's never going to happen...)

Even if it's as simple as saying this:

     class ReadlineSeekAndTell(Interface):
         """You must have readline, seek, and tell if you pass this to me"""
         advise(protocolIsSubsetof=[IFile])


Or, even more briefly, using Samuele's way:

     RST = subproto(IFile,['readline','seek','tell'])



>On the other hand, expecting callers to write stuff to adapt existing
>classes to the requirements of library routines is (IMHO) a non-issue.
>I think that's what PEP 246 was getting at in the statement that "The
>typical Python programmer is an integrator" which you quote. It's
>common to write
>
>     class wrap_source:
>         def __init__(self, source):
>             self.source = source
>         def read(self, n = 1024):
>             return self.source.get_data(n)
>
>     lib_fn(wrap_source(my_source))
>
>So PEP 246 is trying to make writing that sort of boilerplate easier
>(in my view). The *caller* should be calling adapt(), not the callee.

That depends.  It's common in both Zope and Twisted for framework code to 
do the Zope or Twisted equivalents of 'adapt()'.  But yes, it is also 
common to state that some function in effect requires an already adapted 
object.


><snip>
>Which is appropriate is basically down to which came first, string or
>file. But both suffer from the problem of putting all the knowledge
>in one location (and using a type switch as well).

Right.  That's what the point of the open protocols system is.  The problem 
is that in every Python interface system I know of (except PyProtocols), 
you can't declare that package A, protocol X, implies package B, protocol 
Y, unless you are the *author* of package B's protocol Y.

But if package A's author used an open protocol to define protocol X, then 
you can use PyProtocols today to say that it implies package B's protocol 
Y, as long as protocol Y can be adapted to the declaration API.

Translation: anybody who defines protocols for their packages today using 
PyProtocols, will be able to have third parties define adapters to 
interfaces provided by Zope or Twisted, or that are defined using Zope or 
Twisted interfaces.


>The third option, which is the "external registry" allows a *user* of
>the string and file "libraries" (bear with me here...) to say how he
>wants to make strings look like files:
>
><snip>
>So I see PEP 246 as more or less entirely a class based mechanism. It
>has very little to do with constraining (or even documenting) the
>types of function parameters.

PEP 246 specifically said it wasn't tackling that case, however, and I 
personally don't feel that a singleton of such broad scope is practical; it 
seems more appropriate to make protocols responsible for their own adapter 
registries, which is what PyProtocols (and to a lesser extent Twisted) do.


>Of course, a library writer can define interface classes, and the
>adaptation mechanism will allow concrete classes to be made to
>"conform" to those interfaces, but it's not necessary. And given
>the general apathy of the Python community towards interfaces (at
>least as far as I see) I don't imagine this being a very popular use
>pattern.

When designing PyProtocols I did some research on the type-sig, and other 
places...  I got the distinct impression that lots of Pythonistas like 
interfaces, as long as they're abstract base classes.  PyProtocols allows 
that.  But, a protocol can also be a pure symbol, e.g.:

import protocols

myInterface = protocols.Protocol()


Voila.  There's your interface.  Let the user register what they 
will.  Sure, it doesn't *document* anything that isn't stated by its name, 
but that's your users' problem.  ;)  At least they can import 
'yourpackage.myInterface' and register adapters now.


>And describing a PEP 246 style facility in terms of
>interfaces could be a big turn-off. (This applies strongly to your
>PyProtocols code - I looked for something like the pep246.register
>function I suggested above, but I couldn't manage to wade through all
>the IThis and IThat stuff to find it, if it was there...)

Unfortunately, I biased the reference documentation towards explaining the 
architecture and what you need to do to integrate with the framework 
itself, even though 90% of the actual intended audience of PyProtocols will 
never need to do anything like that.  In a sense, you could say that the 
current reference manual is much more of an embedding and extending manual, 
instead of being the Python tutorial.


>Once again, I apologise if I've missed your point. But I hope I've
>explained what I see as the point of PEP 246, and where your proposal
>is going off in a different direction.

I understand what you're saying, although I'm not sure how you interpreted 
PEP 246 that way, when it explicitly states that it *doesn't* cover case 
"e".  And I didn't diverge from PEP 246 in that respect.  What I 
effectively said is, "well, let's make it so that case "e" is irrelevant, 
because there are plenty of __adapt__-capable protocols, and because you 
can register the relationships between them."  Thus, the solution to case 
"e" is effectively:

Don't use built-in types as protocols!


>But the fact remains, that neither PEP 246 nor PyProtocols has any
>need to be in the core, or even in the standard library (yet). Wide
>usage could change that. Usage in something that is destined for the
>standard library could, too, but that one could go the other way (the
>"something" gets rejected because it depends on PEP246/PyProtocols).

Right, that was why I was asking.


>PS This is *way* off-topic for python-dev by now. I suggest that we
>    leave things here. I don't have anything else worth adding...

I suppose we could always resurrect the types-sig....  Although, as Tim 
Peters has frequently suggested, nothing ends discussion more quickly than 
having an implementation available.  :)



From guido@python.org  Thu Jun 12 18:25:54 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 13:25:54 -0400
Subject: [Python-Dev] Proposal to drop f_tstate
In-Reply-To: Your message of "Thu, 12 Jun 2003 18:50:25 +0200."
 <3EE8AF51.1040507@tismer.com>
References: <3EE7E4AB.8030909@tismer.com> <200306121626.h5CGQHZ12068@odiug.zope.com>
 <3EE8AF51.1040507@tismer.com>
Message-ID: <200306121725.h5CHPsG12595@odiug.zope.com>

> >>Therefore, I hereby propose to remove this frame field,
> >>in order to save space.
> ...
> 
> > I notice that all the places that use f_tstate are functions that get
> > a frame passed in.  What makes you believe that those always run in
> > the same thread where the frame was created?
> 
> Schluck!
> I assumed that f_tstate was just some cache, and one would
> never try to look into a different thread.
> This was a wrong assumption.

I don't know that it is.  I just don't know that it isn't, either.

> Sorry, I will und my changes, ASAP.

Where did you make any changes?

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


From staschuk@telusplanet.net  Thu Jun 12 18:36:24 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Thu, 12 Jun 2003 11:36:24 -0600
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121621.h5CGLnq12007@odiug.zope.com>; from guido@python.org on Thu, Jun 12, 2003 at 12:21:49PM -0400
References: <200306121602.h5CG2o712460@localhost.localdomain> <200306121621.h5CGLnq12007@odiug.zope.com>
Message-ID: <20030612113624.C902@tibia.amotlpaa.bogus>

Quoth Guido van Rossum:
> > As an aside, is it planned that sys.exc_traceback,type and value
> > will start emitting DeprecationWarnings any time soon? [...]
> 
> It's hard to put a deprecation warning on these, because they're just
> module attributes.

This came up a day or two ago in c.l.py too.  Bernhard Herzog
suggested:

    What you could do, I think, is turn sys into an instance of a subclass
    of module and make exc_traceback and friends properties in that new
    subclass whose get functions simply return the appropriate value from
    sys.exc_info(). That would actually solve the bug wrt. threading and the
    get function could also issue a warning.  [1]

Seems feasible; but also seems to incur a cost for every attribute
lookup in sys, and might be a bad precedent for fancy attribute
access for modules.

[1]
<http://groups.google.com/groups?selm=6qn0gp23kr.fsf%40salmakis.intevation.de>

-- 
Steven Taschuk              Aral: "Confusion to the enemy, boy."
staschuk@telusplanet.net    Mark: "Turn-about is fair play, sir."
                             -- _Mirror Dance_, Lois McMaster Bujold


From tismer@tismer.com  Thu Jun 12 18:35:44 2003
From: tismer@tismer.com (Christian Tismer)
Date: Thu, 12 Jun 2003 19:35:44 +0200
Subject: [Python-Dev] Proposal to drop f_tstate
In-Reply-To: <200306121725.h5CHPsG12595@odiug.zope.com>
References: <3EE7E4AB.8030909@tismer.com> <200306121626.h5CGQHZ12068@odiug.zope.com>              <3EE8AF51.1040507@tismer.com> <200306121725.h5CHPsG12595@odiug.zope.com>
Message-ID: <3EE8B9F0.6010900@tismer.com>

Guido van Rossum wrote:
>>>>Therefore, I hereby propose to remove this frame field,
>>>>in order to save space.
>>
>>...
>>
>>
>>>I notice that all the places that use f_tstate are functions that get
>>>a frame passed in.  What makes you believe that those always run in
>>>the same thread where the frame was created?
>>
>>Schluck!
>>I assumed that f_tstate was just some cache, and one would
>>never try to look into a different thread.
>>This was a wrong assumption.
> 
> 
> I don't know that it is.  I just don't know that it isn't, either.

It is in fact possible to call PyTraceBack_Here with
any frame, and this could theoretically be from
a different thread.

So I'd better not touch anything. No big deal.

>>Sorry, I will und my changes, ASAP.
> 
> 
> Where did you make any changes?

Oh, just in my Stackless trunk.
I reverted my stuff to the last version.

thanks & cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



From guido@python.org  Thu Jun 12 18:37:45 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 13:37:45 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: Your message of "Thu, 12 Jun 2003 11:36:24 MDT."
 <20030612113624.C902@tibia.amotlpaa.bogus>
References: <200306121602.h5CG2o712460@localhost.localdomain> <200306121621.h5CGLnq12007@odiug.zope.com>
 <20030612113624.C902@tibia.amotlpaa.bogus>
Message-ID: <200306121737.h5CHbjr12671@odiug.zope.com>

> > > As an aside, is it planned that sys.exc_traceback,type and value
> > > will start emitting DeprecationWarnings any time soon? [...]
> > 
> > It's hard to put a deprecation warning on these, because they're just
> > module attributes.
> 
> This came up a day or two ago in c.l.py too.  Bernhard Herzog
> suggested:
> 
>     What you could do, I think, is turn sys into an instance of a subclass
>     of module and make exc_traceback and friends properties in that new
>     subclass whose get functions simply return the appropriate value from
>     sys.exc_info(). That would actually solve the bug wrt. threading and the
>     get function could also issue a warning.  [1]
> 
> Seems feasible; but also seems to incur a cost for every attribute
> lookup in sys, and might be a bad precedent for fancy attribute
> access for modules.
> 
> [1]
> <http://groups.google.com/groups?selm=6qn0gp23kr.fsf%40salmakis.intevation.de>

Well, this *is* the recommended trick when you absolutely, really need
to trap module attribute access.  I don't expect access to sys
attributes to be time-critical, with a possible exception for
sys.stdout (which is used internally by the print statement).  But I
think attribute access, even with a warnings check, can be fast
enough.

The big problem is that it would require a major rewrite of the sys
module, wouldn't it?

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



From pje@telecommunity.com  Thu Jun 12 18:45:00 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jun 2003 13:45:00 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121737.h5CHbjr12671@odiug.zope.com>
References: <Your message of "Thu, 12 Jun 2003 11:36:24 MDT." <20030612113624.C902@tibia.amotlpaa.bogus>
 <200306121602.h5CG2o712460@localhost.localdomain>
 <200306121621.h5CGLnq12007@odiug.zope.com>
 <20030612113624.C902@tibia.amotlpaa.bogus>
Message-ID: <5.1.1.6.0.20030612134209.02fba700@telecommunity.com>

At 01:37 PM 6/12/03 -0400, Guido van Rossum wrote:

>The big problem is that it would require a major rewrite of the sys
>module, wouldn't it?

Under 2.2 this would be easy because you could just do 'sys.__class__ = 
MyNewSysClass'.  Can you still do that in 2.3 as long as 'MyNewSysClass' is 
a non-heap type with a compatible layout?



From mwh@python.net  Thu Jun 12 18:57:04 2003
From: mwh@python.net (Michael Hudson)
Date: Thu, 12 Jun 2003 18:57:04 +0100
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <5.1.1.6.0.20030612134209.02fba700@telecommunity.com> ("Phillip
 J. Eby"'s message of "Thu, 12 Jun 2003 13:45:00 -0400")
References: <Your message of "Thu, 12 Jun 2003 11:36:24 MDT."
 <20030612113624.C902@tibia.amotlpaa.bogus>
 <200306121602.h5CG2o712460@localhost.localdomain>
 <200306121621.h5CGLnq12007@odiug.zope.com>
 <20030612113624.C902@tibia.amotlpaa.bogus>
 <5.1.1.6.0.20030612134209.02fba700@telecommunity.com>
Message-ID: <2m7k7rgowf.fsf@starship.python.net>

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

> At 01:37 PM 6/12/03 -0400, Guido van Rossum wrote:
>
>>The big problem is that it would require a major rewrite of the sys
>>module, wouldn't it?
>
> Under 2.2 this would be easy because you could just do 'sys.__class__
> = MyNewSysClass'.  Can you still do that in 2.3 as long as
> 'MyNewSysClass' is a non-heap type with a compatible layout?

No.

Cheers,
M.

-- 
  The gripping hand is really that there are morons everywhere, it's
  just that the Americon morons are funnier than average.
                              -- Pim van Riezen, alt.sysadmin.recovery


From guido@python.org  Thu Jun 12 19:04:27 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 14:04:27 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: Your message of "Thu, 12 Jun 2003 13:45:00 EDT."
 <5.1.1.6.0.20030612134209.02fba700@telecommunity.com>
References: <Your message of "Thu, 12 Jun 2003 11:36:24 MDT." <20030612113624.C902@tibia.amotlpaa.bogus> <200306121602.h5CG2o712460@localhost.localdomain> <200306121621.h5CGLnq12007@odiug.zope.com> <20030612113624.C902@tibia.amotlpaa.bogus>
 <5.1.1.6.0.20030612134209.02fba700@telecommunity.com>
Message-ID: <200306121804.h5CI4RO12821@odiug.zope.com>

> >The big problem is that it would require a major rewrite of the sys
> >module, wouldn't it?
> 
> Under 2.2 this would be easy because you could just do 'sys.__class__ = 
> MyNewSysClass'.  Can you still do that in 2.3 as long as 'MyNewSysClass' is 
> a non-heap type with a compatible layout?

I very much doubt that this worked in any version of Python 2.2 or
later.

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


From bh@intevation.de  Thu Jun 12 19:07:07 2003
From: bh@intevation.de (Bernhard Herzog)
Date: 12 Jun 2003 20:07:07 +0200
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121737.h5CHbjr12671@odiug.zope.com>
References: <200306121602.h5CG2o712460@localhost.localdomain>
 <200306121621.h5CGLnq12007@odiug.zope.com>
 <20030612113624.C902@tibia.amotlpaa.bogus>
 <200306121737.h5CHbjr12671@odiug.zope.com>
Message-ID: <6q65nbnp9w.fsf@salmakis.intevation.de>

Guido van Rossum <guido@python.org> writes:

> >     What you could do, I think, is turn sys into an instance of a subclass
> >     of module and make exc_traceback and friends properties in that new
> >     subclass whose get functions simply return the appropriate value from
> >     sys.exc_info(). That would actually solve the bug wrt. threading and the
> >     get function could also issue a warning.  [1]
> > 
> > Seems feasible; but also seems to incur a cost for every attribute
> > lookup in sys,

Only for those that are implemented as properties, I think.

> > and might be a bad precedent for fancy attribute
> > access for modules.

Well, some of us would actually like to have this sometimes :)

[...]
> The big problem is that it would require a major rewrite of the sys
> module, wouldn't it?

It would also mean that type(sys) is no longer ModuleType, right? There
is some code in the standard library that relies on this, even a few
test cases. The library could easily be fixed, but chances are others
also rely on this.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                           http://www.mapit.de/


From pje@telecommunity.com  Thu Jun 12 19:10:01 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jun 2003 14:10:01 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121804.h5CI4RO12821@odiug.zope.com>
References: <Your message of "Thu, 12 Jun 2003 13:45:00 EDT." <5.1.1.6.0.20030612134209.02fba700@telecommunity.com>
 <Your message of "Thu, 12 Jun 2003 11:36:24 MDT." <20030612113624.C902@tibia.amotlpaa.bogus>
 <200306121602.h5CG2o712460@localhost.localdomain>
 <200306121621.h5CGLnq12007@odiug.zope.com>
 <20030612113624.C902@tibia.amotlpaa.bogus>
 <5.1.1.6.0.20030612134209.02fba700@telecommunity.com>
Message-ID: <5.1.1.6.0.20030612140541.02417480@telecommunity.com>

At 02:04 PM 6/12/03 -0400, Guido van Rossum wrote:
> > >The big problem is that it would require a major rewrite of the sys
> > >module, wouldn't it?
> >
> > Under 2.2 this would be easy because you could just do 'sys.__class__ =
> > MyNewSysClass'.  Can you still do that in 2.3 as long as 
> 'MyNewSysClass' is
> > a non-heap type with a compatible layout?
>
>I very much doubt that this worked in any version of Python 2.2 or
>later.

Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
 >>> from types import ModuleType
 >>> import sys
 >>> class NewSys(ModuleType):
         __slots__ = ()
         def exc_type(self):
                 return self.__dict__['exc_type']
         exc_type = property(exc_type)

 >>> sys.__class__ = NewSys
 >>> try:
         raise TypeError
except:
         print sys.exc_type


exceptions.TypeError
 >>>

 >>> sys.exc_type = 1
Traceback (most recent call last):
   File "<pyshell#33>", line 1, in ?
     sys.exc_type = 1
AttributeError: can't set attribute
 >>> sys.__class__ = ModuleType
 >>> sys.exc_type = 1
 >>>



From guido@python.org  Thu Jun 12 19:22:21 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 14:22:21 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: Your message of "Thu, 12 Jun 2003 14:10:01 EDT."
 <5.1.1.6.0.20030612140541.02417480@telecommunity.com>
References: <Your message of "Thu, 12 Jun 2003 13:45:00 EDT." <5.1.1.6.0.20030612134209.02fba700@telecommunity.com> <Your message of "Thu, 12 Jun 2003 11:36:24 MDT." <20030612113624.C902@tibia.amotlpaa.bogus> <200306121602.h5CG2o712460@localhost.localdomain> <200306121621.h5CGLnq12007@odiug.zope.com> <20030612113624.C902@tibia.amotlpaa.bogus> <5.1.1.6.0.20030612134209.02fba700@telecommunity.com>
 <5.1.1.6.0.20030612140541.02417480@telecommunity.com>
Message-ID: <200306121822.h5CIML812986@odiug.zope.com>

> > > >The big problem is that it would require a major rewrite of the sys
> > > >module, wouldn't it?
> > >
> > > Under 2.2 this would be easy because you could just do 'sys.__class__ =
> > > MyNewSysClass'.  Can you still do that in 2.3 as long as 
> > 'MyNewSysClass' is
> > > a non-heap type with a compatible layout?
> >
> >I very much doubt that this worked in any version of Python 2.2 or
> >later.
> 
> Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> IDLE 0.8 -- press F1 for help
>  >>> from types import ModuleType
>  >>> import sys
>  >>> class NewSys(ModuleType):
>          __slots__ = ()
>          def exc_type(self):
>                  return self.__dict__['exc_type']
>          exc_type = property(exc_type)
> 
>  >>> sys.__class__ = NewSys
>  >>> try:
>          raise TypeError
> except:
>          print sys.exc_type
> 
> 
> exceptions.TypeError
>  >>>
> 
>  >>> sys.exc_type = 1
> Traceback (most recent call last):
>    File "<pyshell#33>", line 1, in ?
>      sys.exc_type = 1
> AttributeError: can't set attribute
>  >>> sys.__class__ = ModuleType
>  >>> sys.exc_type = 1
>  >>>

OK, so it worked.  It doesn't work in 2.3.  But something else might
work.

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


From pje@telecommunity.com  Thu Jun 12 19:21:21 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jun 2003 14:21:21 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121822.h5CIML812986@odiug.zope.com>
References: <Your message of "Thu, 12 Jun 2003 14:10:01 EDT." <5.1.1.6.0.20030612140541.02417480@telecommunity.com>
 <Your message of "Thu, 12 Jun 2003 13:45:00 EDT." <5.1.1.6.0.20030612134209.02fba700@telecommunity.com>
 <Your message of "Thu, 12 Jun 2003 11:36:24 MDT." <20030612113624.C902@tibia.amotlpaa.bogus>
 <200306121602.h5CG2o712460@localhost.localdomain>
 <200306121621.h5CGLnq12007@odiug.zope.com>
 <20030612113624.C902@tibia.amotlpaa.bogus>
 <5.1.1.6.0.20030612134209.02fba700@telecommunity.com>
 <5.1.1.6.0.20030612140541.02417480@telecommunity.com>
Message-ID: <5.1.1.6.0.20030612141845.0240e0b0@telecommunity.com>

At 02:22 PM 6/12/03 -0400, Guido van Rossum wrote:

>OK, so it worked.  It doesn't work in 2.3.  But something else might
>work.

My question was whether it would work with a *C* subclass of 
ModuleType.  In which case, presumably C code could set the type after 
initializing the sys module.



From guido@python.org  Thu Jun 12 19:27:48 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 14:27:48 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: Your message of "Thu, 12 Jun 2003 14:21:21 EDT."
 <5.1.1.6.0.20030612141845.0240e0b0@telecommunity.com>
References: <Your message of "Thu, 12 Jun 2003 14:10:01 EDT." <5.1.1.6.0.20030612140541.02417480@telecommunity.com> <Your message of "Thu, 12 Jun 2003 13:45:00 EDT." <5.1.1.6.0.20030612134209.02fba700@telecommunity.com> <Your message of "Thu, 12 Jun 2003 11:36:24 MDT." <20030612113624.C902@tibia.amotlpaa.bogus> <200306121602.h5CG2o712460@localhost.localdomain> <200306121621.h5CGLnq12007@odiug.zope.com> <20030612113624.C902@tibia.amotlpaa.bogus> <5.1.1.6.0.20030612134209.02fba700@telecommunity.com> <5.1.1.6.0.20030612140541.02417480@telecommunity.com>
 <5.1.1.6.0.20030612141845.0240e0b0@telecommunity.com>
Message-ID: <200306121827.h5CIRm113088@odiug.zope.com>

> >OK, so it worked.  It doesn't work in 2.3.  But something else might
> >work.
> 
> My question was whether it would work with a *C* subclass of 
> ModuleType.  In which case, presumably C code could set the type after 
> initializing the sys module.

Right, this could work (even though in 2.3, the module type is no
longer subclassable).

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


From tismer@tismer.com  Thu Jun 12 20:39:58 2003
From: tismer@tismer.com (Christian Tismer)
Date: Thu, 12 Jun 2003 21:39:58 +0200
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121737.h5CHbjr12671@odiug.zope.com>
References: <200306121602.h5CG2o712460@localhost.localdomain> <200306121621.h5CGLnq12007@odiug.zope.com>              <20030612113624.C902@tibia.amotlpaa.bogus> <200306121737.h5CHbjr12671@odiug.zope.com>
Message-ID: <3EE8D70E.1010800@tismer.com>

Guido van Rossum wrote:

>>>>As an aside, is it planned that sys.exc_traceback,type and value
>>>>will start emitting DeprecationWarnings any time soon? [...]
>>>
>>>It's hard to put a deprecation warning on these, because they're just
>>>module attributes.
>>
>>This came up a day or two ago in c.l.py too.  Bernhard Herzog
>>suggested:

...

> Well, this *is* the recommended trick when you absolutely, really need
> to trap module attribute access.  I don't expect access to sys
> attributes to be time-critical, with a possible exception for
> sys.stdout (which is used internally by the print statement).  But I
> think attribute access, even with a warnings check, can be fast
> enough.

I looked into the execution path of PyObject_GenericGetAttr.
This first finds the type dictionary and sees if it can find
something there. So access to special objects appears to be
quite fast.
The drawback is that only after searching all of the mro
dicts, _PyType_Lookup gives up, and then the instance
dict is inspected.

> The big problem is that it would require a major rewrite of the sys
> module, wouldn't it?

I used a derived module class for my stackless module
as well, just in order to define a couple of extra atributes,
not aware of the extra costs for this.

This is of course not so cheap, and with the current
implementation, only the special attributes of
sys would become rather cheap, which would in fact
involve some work to do, because most probably most
of the sys attributes might be considered special.

Maybe, assuming that only very few sys attributes should
grow special treatment, a special getattro() would make
sense that looks into the instance(module) dict, first?

Some half-baked thoughts:

 From another POV, modules are always just singletons,
nobody really wants to create a new module type.
Instead, they want a module with special attributes,
which is a singleton instance. I think that after
module creation, the class is no longer needed so much,
since a module is created once.
In a way, I think one would not want to create instances
at all, but to let this single type act as class
and instance at the same time.
In practice, this could mean that a module is like a new
type, which slot definitions, which define slots in the
same object, plus the extra dictionary for ordinary
module citizens.
The type "module" becomes a metatype.
The new modules become types which cannot
create instances, but which carry both
slot definitions and slots.

just a rough idea -- chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



From guido@python.org  Thu Jun 12 20:54:28 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 15:54:28 -0400
Subject: [Python-Dev] Where to put the interrupt module?
Message-ID: <200306121954.h5CJsSF14644@odiug.zope.com>

IDLEfork, now in Lib/idlelib, uses a new C extension, the 'interrupt'
module.  This is a truly minimal, and generally useful, module to
provide a way to cause a KeyboardInterrupt in the main thread from a
secondary thread.  I propose to move this to Modules, and make it a
toplevel module.  This is the easiest thing in order to get it
compiled and built for various platforms.

Any problems?

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


From jacobs@penguin.theopalgroup.com  Thu Jun 12 21:01:39 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Thu, 12 Jun 2003 16:01:39 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306121954.h5CJsSF14644@odiug.zope.com>
Message-ID: <Pine.LNX.4.44.0306121558540.13850-100000@penguin.theopalgroup.com>

On Thu, 12 Jun 2003, Guido van Rossum wrote:
> IDLEfork, now in Lib/idlelib, uses a new C extension, the 'interrupt'
> module.  This is a truly minimal, and generally useful, module to
> provide a way to cause a KeyboardInterrupt in the main thread from a
> secondary thread.  I propose to move this to Modules, and make it a
> toplevel module.  This is the easiest thing in order to get it
> compiled and built for various platforms.

I haven't looked, but is it possible to make it raise an arbitrary
exception?  Last time I read the PyErr_CheckSignals code it looked possible. 
(That was yesterday, actually, regarding problems with the SSL module and
KeyboardInterrupts).

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From guido@python.org  Thu Jun 12 21:07:33 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 16:07:33 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: Your message of "Thu, 12 Jun 2003 16:01:39 EDT."
 <Pine.LNX.4.44.0306121558540.13850-100000@penguin.theopalgroup.com>
References: <Pine.LNX.4.44.0306121558540.13850-100000@penguin.theopalgroup.com>
Message-ID: <200306122007.h5CK7Xi14744@odiug.zope.com>

> I haven't looked, but is it possible to make it raise an arbitrary
> exception?  Last time I read the PyErr_CheckSignals code it looked possible. 
> (That was yesterday, actually, regarding problems with the SSL module and
> KeyboardInterrupts).

The interrupt module currently uses PyErr_SetInterrupt(), which can
only raise KeyboardInterrupt.

Let's not generalize this until there's a need.  Then, let whoever has
the need add the generalization.

I'm actually a bit wary of such a generalization, because
KeyboardInterrupt is currently the only *asynchronous* exception that
code needs to worry about.  There is plenty of code that gives
KeyboardInterrupt special treatment, typically of the form:

  while MoreWorkToDo:
      try:
	  ...run a chunk of work which may raise arbitrary exceptions...
      except KeyboardInterrupt:
	  raise # Don't keep going in this case
      except:
	  ...report the error and continue...

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


From neal@metaslash.com  Thu Jun 12 21:12:32 2003
From: neal@metaslash.com (Neal Norwitz)
Date: Thu, 12 Jun 2003 16:12:32 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306122007.h5CK7Xi14744@odiug.zope.com>
References: <Pine.LNX.4.44.0306121558540.13850-100000@penguin.theopalgroup.com>
 <200306122007.h5CK7Xi14744@odiug.zope.com>
Message-ID: <20030612201231.GA30348@epoch.metaslash.com>

On Thu, Jun 12, 2003 at 04:07:33PM -0400, Guido van Rossum wrote:
> > I haven't looked, but is it possible to make it raise an arbitrary
> > exception?  Last time I read the PyErr_CheckSignals code it looked possible. 
> > (That was yesterday, actually, regarding problems with the SSL module and
> > KeyboardInterrupts).
> 
> The interrupt module currently uses PyErr_SetInterrupt(), which can
> only raise KeyboardInterrupt.
> 
> Let's not generalize this until there's a need.  Then, let whoever has
> the need add the generalization.
> 
> I'm actually a bit wary of such a generalization, because
> KeyboardInterrupt is currently the only *asynchronous* exception that
> code needs to worry about.  There is plenty of code that gives
> KeyboardInterrupt special treatment, typically of the form:
> 
>   while MoreWorkToDo:
>       try:
> 	  ...run a chunk of work which may raise arbitrary exceptions...
>       except KeyboardInterrupt:
> 	  raise # Don't keep going in this case
>       except:
> 	  ...report the error and continue...

What about SystemExit?

Neal


From guido@python.org  Thu Jun 12 21:35:30 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 16:35:30 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: Your message of "Thu, 12 Jun 2003 16:12:32 EDT."
 <20030612201231.GA30348@epoch.metaslash.com>
References: <Pine.LNX.4.44.0306121558540.13850-100000@penguin.theopalgroup.com> <200306122007.h5CK7Xi14744@odiug.zope.com>
 <20030612201231.GA30348@epoch.metaslash.com>
Message-ID: <200306122035.h5CKZUZ14812@odiug.zope.com>

> > I'm actually a bit wary of such a generalization, because
> > KeyboardInterrupt is currently the only *asynchronous* exception that
> > code needs to worry about.  There is plenty of code that gives
> > KeyboardInterrupt special treatment, typically of the form:
> > 
> >   while MoreWorkToDo:
> >       try:
> > 	  ...run a chunk of work which may raise arbitrary exceptions...
> >       except KeyboardInterrupt:
> > 	  raise # Don't keep going in this case
> >       except:
> > 	  ...report the error and continue...
> 
> What about SystemExit?

It was only an example!

What should be done with SystemExit depends on what the application is
trying to do.  In an interactive Python shell, you probably want to
re-raise it.  But in other cases, SystemExit is an error like all
others.  (For example, consider a loop that walks a directory tree and
runs testcases found in files named "test.py".)

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


From Jack.Jansen@cwi.nl  Thu Jun 12 21:37:48 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Thu, 12 Jun 2003 22:37:48 +0200
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306121954.h5CJsSF14644@odiug.zope.com>
Message-ID: <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl>

On donderdag, jun 12, 2003, at 21:54 Europe/Amsterdam, Guido van Rossum 
wrote:

> IDLEfork, now in Lib/idlelib, uses a new C extension, the 'interrupt'
> module.  This is a truly minimal, and generally useful, module to
> provide a way to cause a KeyboardInterrupt in the main thread from a
> secondary thread.  I propose to move this to Modules, and make it a
> toplevel module.  This is the easiest thing in order to get it
> compiled and built for various platforms.

+1 on the functionality. But: if it's so small why not simply put it in 
sys?
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From jacobs@penguin.theopalgroup.com  Thu Jun 12 21:44:58 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Thu, 12 Jun 2003 16:44:58 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306122007.h5CK7Xi14744@odiug.zope.com>
Message-ID: <Pine.LNX.4.44.0306121631140.13936-100000@penguin.theopalgroup.com>

On Thu, 12 Jun 2003, Guido van Rossum wrote:
> The interrupt module currently uses PyErr_SetInterrupt(), which can
> only raise KeyboardInterrupt.
> 
> Let's not generalize this until there's a need.  Then, let whoever has
> the need add the generalization.

In that past, there have been a few times where it would have been very
convenient to terminate/signal another thread by posting an exception to it.
Using KeyboardInterrupt to do so is okay, although it seems like something
of a kludge.

> I'm actually a bit wary of such a generalization, because
> KeyboardInterrupt is currently the only *asynchronous* exception that
> code needs to worry about.  There is plenty of code that gives
> KeyboardInterrupt special treatment, [..]

Code that gives special status to KeyboardInterrupt doesn't worry me at all. 
What I am wary of is code that is not written to be exception safe in the
presence of unexpected exceptions (not just asynchronous ones).  The example
I was working on yesterday involved KeyboardInterrupts generated from an SSL
socket in httplib's SSL readline method.  A keyboard interrupt will result
in data read from the socket and then stored in a local variable to be lost. 
Of course, this error wasn't very likely before I patched the SSL module to
check for interrupts, but that is beside the point.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From jacobs@penguin.theopalgroup.com  Thu Jun 12 21:50:44 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Thu, 12 Jun 2003 16:50:44 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306122035.h5CKZUZ14812@odiug.zope.com>
Message-ID: <Pine.LNX.4.44.0306121645250.13936-100000@penguin.theopalgroup.com>

On Thu, 12 Jun 2003, Guido van Rossum wrote:
> > > I'm actually a bit wary of such a generalization, because
> > > KeyboardInterrupt is currently the only *asynchronous* exception that
> > > code needs to worry about.  There is plenty of code that gives
> > > KeyboardInterrupt special treatment, typically of the form:
> > > 
> > >   while MoreWorkToDo:
> > >       try:
> > > 	  ...run a chunk of work which may raise arbitrary exceptions...
> > >       except KeyboardInterrupt:
> > > 	  raise # Don't keep going in this case
> > >       except:
> > > 	  ...report the error and continue...
> > 
> > What about SystemExit?
> 
> It was only an example!
> 
> What should be done with SystemExit depends on what the application is
> trying to do.  In an interactive Python shell, you probably want to
> re-raise it.  But in other cases, SystemExit is an error like all
> others.  (For example, consider a loop that walks a directory tree and
> runs testcases found in files named "test.py".)

Not to be pedantic, but isn't the range of interpretations of SystemExit
exactly analogous to that of KeyboardInterrupt?  Also remember that pounding
Control-C isn't the only way for a process or thread to get a SIGINT (and
thus a KeyboardInterrupt).

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From guido@python.org  Thu Jun 12 21:51:45 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 16:51:45 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: Your message of "Thu, 12 Jun 2003 16:44:58 EDT."
 <Pine.LNX.4.44.0306121631140.13936-100000@penguin.theopalgroup.com>
References: <Pine.LNX.4.44.0306121631140.13936-100000@penguin.theopalgroup.com>
Message-ID: <200306122051.h5CKpjJ14933@odiug.zope.com>

> In that past, there have been a few times where it would have been
> very convenient to terminate/signal another thread by posting an
> exception to it.  Using KeyboardInterrupt to do so is okay, although
> it seems like something of a kludge.

This gets into the general discussion about whether threads should be
stoppable.

Also, this mechanism can *only* interrupt the main thread.  (That's
even true of the more generalized version you were thinking of.)

> Code that gives special status to KeyboardInterrupt doesn't worry me
> at all. What I am wary of is code that is not written to be
> exception safe in the presence of unexpected exceptions (not just
> asynchronous ones).  The example I was working on yesterday involved
> KeyboardInterrupts generated from an SSL socket in httplib's SSL
> readline method.  A keyboard interrupt will result in data read from
> the socket and then stored in a local variable to be lost. Of
> course, this error wasn't very likely before I patched the SSL
> module to check for interrupts, but that is beside the point.

That's a problem that'll always remain.

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


From guido@python.org  Thu Jun 12 21:54:17 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 16:54:17 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: Your message of "Thu, 12 Jun 2003 16:50:44 EDT."
 <Pine.LNX.4.44.0306121645250.13936-100000@penguin.theopalgroup.com>
References: <Pine.LNX.4.44.0306121645250.13936-100000@penguin.theopalgroup.com>
Message-ID: <200306122054.h5CKsHO14961@odiug.zope.com>

> Not to be pedantic, but isn't the range of interpretations of SystemExit
> exactly analogous to that of KeyboardInterrupt?

I don't understand what you mean here.  I thought I gave an example
where it wasn't.

> Also remember that pounding
> Control-C isn't the only way for a process or thread to get a SIGINT (and
> thus a KeyboardInterrupt).

I'm aware of kill, yes. :-)

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


From jacobs@penguin.theopalgroup.com  Thu Jun 12 21:56:30 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Thu, 12 Jun 2003 16:56:30 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306122051.h5CKpjJ14933@odiug.zope.com>
Message-ID: <Pine.LNX.4.44.0306121653130.14462-100000@penguin.theopalgroup.com>

On Thu, 12 Jun 2003, Guido van Rossum wrote:
> > In that past, there have been a few times where it would have been
> > very convenient to terminate/signal another thread by posting an
> > exception to it.  Using KeyboardInterrupt to do so is okay, although
> > it seems like something of a kludge.
> 
> This gets into the general discussion about whether threads should be
> stoppable.

True -- I am of the opinion that threads should be cooperatively stoppable,
but not preemptively stoppable, if that makes sense.  Asynchronous exceptions
are the ideal way of implementing this, since the main interpreter loop is
essentially already instrumented to handle them.

> Also, this mechanism can *only* interrupt the main thread.  (That's
> even true of the more generalized version you were thinking of.)

Ah.. that sounds familiar.  I knew there was a reason I didn't pursue this
avenue farther last time I poked through that code.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From guido@python.org  Thu Jun 12 21:58:39 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 16:58:39 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: Your message of "Thu, 12 Jun 2003 22:37:48 +0200."
 <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl>
References: <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl>
Message-ID: <200306122058.h5CKwd515011@odiug.zope.com>

> > IDLEfork, now in Lib/idlelib, uses a new C extension, the 'interrupt'
> > module.  This is a truly minimal, and generally useful, module to
> > provide a way to cause a KeyboardInterrupt in the main thread from a
> > secondary thread.  I propose to move this to Modules, and make it a
> > toplevel module.  This is the easiest thing in order to get it
> > compiled and built for various platforms.
> 
> +1 on the functionality. But: if it's so small why not simply put it in 
> sys?

Hm, that's not bad.  It should be called sys.interrupt_main() then.

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


From gerrit@nl.linux.org  Thu Jun 12 22:12:57 2003
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Thu, 12 Jun 2003 23:12:57 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
Message-ID: <20030612211257.GA16269@nl.linux.org>

Hi,

I am unable to compile Python 2.3 + _tkinter (latest CVS) with Redhat 9.
Earlier suggestions on python-dev and SF won't help or arise other problems.
The _tkinter module won't be compiled:

I get the following error messages when I do nothing:
Modules/_tkinter.c:96:2: #error "unsupported Tcl configuration"
Modules/_tkinter.c: In function `AsObj':
Modules/_tkinter.c:947: warning: passing arg 1 of `Tcl_NewUnicodeObj' from incompatible pointer type
Modules/_tkinter.c: In function `FromObj':
Modules/_tkinter.c:1073: warning: passing arg 1 of `PyUnicodeUCS2_FromUnicode' from incompatible pointer type

About same problem was arised in this message:
http://mail.python.org/pipermail/python-dev/2003-April/034724.html
And in SF#719880.

But there are some differences.

This is after SF#719880 has been applied.
When I remove the test, I do *not* get a working version of Tkinter:
$ ./python
Python 2.3b1+ (#1, Jun 12 2003, 22:15:45)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
0 >>> import Tkinter
1 >>> Tkinter._test()
Segmentation fault

Later in the thread, the suggestion was made to compile with
--enable-unicode=ucs4. However, then I get:

*** WARNING: renaming "array" since importing it failed: build/lib.linux-i686-2.3/array.so: undefined symbol: PyUnicodeUCS2_FromUnicode
*** WARNING: renaming "_testcapi" since importing it failed: build/lib.linux-i686-2.3/_testcapi.so: undefined symbol: PyUnicodeUCS2_Decode
*** WARNING: renaming "unicodedata" since importing it failed: build/lib.linux-i686-2.3/unicodedata.so: undefined symbol: PyUnicodeUCS2_FromUnicode
*** WARNING: renaming "_locale" since importing it failed: build/lib.linux-i686-2.3/_locale.so: undefined symbol: PyUnicodeUCS2_AsWideChar
*** WARNING: renaming "cPickle" since importing it failed: build/lib.linux-i686-2.3/cPickle.so: undefined symbol: PyUnicodeUCS2_AsUTF8String
*** WARNING: renaming "pyexpat" since importing it failed: build/lib.linux-i686-2.3/pyexpat.so: undefined symbol: PyUnicodeUCS2_DecodeUTF8

Tkinter now works, but array, locale, cPickle, etc. are not present.

How can I solve this problem? Is it a bug? Or is it something on my system?

Gerrit.

-- 
234. If a shipbuilder build a boat of sixty gur for a man, he shall pay
him a fee of two shekels in money.
        -- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
	http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
	http://www.sp.nl/


From martin@v.loewis.de  Thu Jun 12 22:21:46 2003
From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 12 Jun 2003 23:21:46 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <20030612211257.GA16269@nl.linux.org>
References: <20030612211257.GA16269@nl.linux.org>
Message-ID: <3EE8EEEA.5080302@v.loewis.de>

Gerrit Holl wrote:

> How can I solve this problem? Is it a bug? Or is it something on my system?

make again (after removing ./build), no, and yes: it is a Redhat 9 system.

Ask Redhat why they chose to hack Tcl to better accomodate Python.

Regards,
Martin




From jepler@unpythonic.net  Thu Jun 12 22:21:03 2003
From: jepler@unpythonic.net (Jeff Epler)
Date: Thu, 12 Jun 2003 16:21:03 -0500
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <20030612211257.GA16269@nl.linux.org>
References: <20030612211257.GA16269@nl.linux.org>
Message-ID: <20030612212102.GH23024@unpythonic.net>

On Thu, Jun 12, 2003 at 11:12:57PM +0200, Gerrit Holl wrote:
> Tkinter now works, but array, locale, cPickle, etc. are not present.

You'll probably need to remove the shared modules that were built with
the different UCS setting, then "make" again.

Jeff


From barry@python.org  Thu Jun 12 22:30:30 2003
From: barry@python.org (Barry Warsaw)
Date: 12 Jun 2003 17:30:30 -0400
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9
 (post-SF#719880)
In-Reply-To: <20030612212102.GH23024@unpythonic.net>
References: <20030612211257.GA16269@nl.linux.org>
 <20030612212102.GH23024@unpythonic.net>
Message-ID: <1055453429.5434.70.camel@barry>

On Thu, 2003-06-12 at 17:21, Jeff Epler wrote:
> On Thu, Jun 12, 2003 at 11:12:57PM +0200, Gerrit Holl wrote:
> > Tkinter now works, but array, locale, cPickle, etc. are not present.
> 
> You'll probably need to remove the shared modules that were built with
> the different UCS setting, then "make" again.

Yep, I've expanded my config options from --with-pydebug to include
--enable-unicode=ucs4

-Barry




From aahz@pythoncraft.com  Thu Jun 12 22:39:26 2003
From: aahz@pythoncraft.com (Aahz)
Date: Thu, 12 Jun 2003 17:39:26 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <3EE8D70E.1010800@tismer.com>
References: <200306121602.h5CG2o712460@localhost.localdomain> <200306121621.h5CGLnq12007@odiug.zope.com> <20030612113624.C902@tibia.amotlpaa.bogus> <200306121737.h5CHbjr12671@odiug.zope.com> <3EE8D70E.1010800@tismer.com>
Message-ID: <20030612213926.GA3559@panix.com>

On Thu, Jun 12, 2003, Christian Tismer wrote:
>
> I looked into the execution path of PyObject_GenericGetAttr.
> This first finds the type dictionary and sees if it can find
> something there. So access to special objects appears to be
> quite fast.
> The drawback is that only after searching all of the mro
> dicts, _PyType_Lookup gives up, and then the instance
> dict is inspected.

Yes.  Ping, Guido, and I were working on a patch for this, but stalled
when our solution generated slower results for attributes in the most
immediate base class.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From jmiller@stsci.edu  Thu Jun 12 22:49:33 2003
From: jmiller@stsci.edu (Todd Miller)
Date: 12 Jun 2003 17:49:33 -0400
Subject: [Python-Dev] PEP-311 operational?
Message-ID: <1055454573.15638.76.camel@halloween.stsci.edu>

I've been trying for a day or so to use the new PyGILState_Ensure() and
PyGILState_Release() calls.  I started with a Python multi-threaded test
case and a simple hypothetical extension function.  I want to protect
the extension function in case it gets called from an embedded context
by a non-Python thread.  (In truth, I started with numarray stuff where
this makes slightly more sense;  I wanted to protect an API function.)

It is now my impression that an extension function with the following
core contents: 

{ PyGILState_STATE state = PyGILState_Ensure();
  int i;
  for(i=0; i<100000; i++);
  PyGILState_Release(state);
}

will deadlock (in the Ensure), provided it is called from some secondary
thread from Python.  I thought this would be OK and that the
Ensure/Release would essentially be a noop.  Did I misread the PEP?  Is
the PEP-311 code finished yet?

(I tried this under Red Hat 8 and Windows 2000 pro with Python CVS)

Thanks,
Todd




From gerrit@nl.linux.org  Thu Jun 12 22:50:31 2003
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Thu, 12 Jun 2003 23:50:31 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <3EE8EEEA.5080302@v.loewis.de>
References: <20030612211257.GA16269@nl.linux.org> <3EE8EEEA.5080302@v.loewis.de>
Message-ID: <20030612215031.GA29120@nl.linux.org>

"Martin v. Löwis" wrote:
> Gerrit Holl wrote:
> >How can I solve this problem? Is it a bug? Or is it something on my system?
> 
> make again (after removing ./build), no, and yes: it is a Redhat 9 system.

Thanks!

I am probably not the only one encountering this problem and I didn't
find this behaviour documented in the README. Should it be? If so,
should I sent a docpatch? It's Redhat's failure, of course, but a lot
of unsuspecting RH-users are out (t)here...

> Ask Redhat why they chose to hack Tcl to better accomodate Python.

I take it 'better' is ironically here? :) (I am not good at irony,
if it isn't I haven't understood it very well ;).
Redhat does have bugfix updates, I will look if they know something
about this tomorrow (IIRC they have a buglist).

Gerrit.

-- 
1. If any one ensnare another, putting a ban upon him, but he can not
prove it, then he that ensnared him shall be put to death.
        -- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
	http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
	http://www.sp.nl/


From martin@v.loewis.de  Thu Jun 12 23:19:04 2003
From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jun 2003 00:19:04 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <20030612215031.GA29120@nl.linux.org>
References: <20030612211257.GA16269@nl.linux.org> <3EE8EEEA.5080302@v.loewis.de> <20030612215031.GA29120@nl.linux.org>
Message-ID: <3EE8FC58.3010106@v.loewis.de>

Gerrit Holl wrote:

> I am probably not the only one encountering this problem and I didn't
> find this behaviour documented in the README. Should it be? If so,
> should I sent a docpatch? 

Sure: You might want to revise the entire Redhat section in README.

>>Ask Redhat why they chose to hack Tcl to better accomodate Python.
> 
> 
> I take it 'better' is ironically here? :) 

Well, they decided to built Python 2.2 in UCS-4 mode, which is,
in general, a good thing, except that it doesn't work. In particular,
sre and _tkinter don't work well; _tkinter does not work at all.
Instead of fixing _tkinter (which I now did for Python 2.3), they
chose to hack Tcl instead, to extend it to UCS-4 mode.

Now I have to deal with standard Tcl, which is UCS-2, and can support
both UCS-2 and UCS-4 Python _tkinter with that (2.2 would mandate
UCS-2 Python for _tkinter). I also have to support Redhat Tcl, which
is UCS-4. I chose to only support this in combination with UCS-4
Python. If anybody wants the combination Redhat Tcl + UCS-2 Python,
feel free to develop a patch.

> Redhat does have bugfix updates, I will look if they know something
> about this tomorrow (IIRC they have a buglist).

It's not a bug. They *really* made this change to support their own
build of Python. Unfortunately, they have thereby tied Python to UCS-4
on Redhat 9. Their change is a hack, though, as Tcl does not really
support UCS-4 - it merely compiles now, but don't dare to use non-BMP
characters.

Once standard Tcl supports UCS-4, we probably need to look into this
again.

Regards,
Martin




From mal@lemburg.com  Thu Jun 12 23:22:08 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 13 Jun 2003 00:22:08 +0200
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: <200306121344.h5CDiUi11167@odiug.zope.com>
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz> <200306121344.h5CDiUi11167@odiug.zope.com>
Message-ID: <3EE8FD10.2060108@lemburg.com>

Guido van Rossum wrote:
>>>Types with constructors that insist on an argument are problematic to
>>>generic code that tries to instantiate a type by simply calling it.
>>
>>Why on earth would you be trying to instantiate something
>>without having any idea what parameters are required?
> 
> It could be the other way though: something could have a protocol
> where you can pass in a factory function that's called without
> arguments, and maybe you'd like to be able to pass it a built-in
> type.  Something very close to this happened to me when testing Zope 3
> filesystem synchronization.

Very close is still not good enough :-)

I can't really believe that you're designing protocols that have
to call unknown factory functions to see whether they do something
particular or not.

If you really happen to have a need for this, why can't you
introduce factory functions which take care of your particular
use case ? I don't think it's common enough to risk accidental
progamming errors in other user's code.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 13 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        11 days left



From drifty@alum.berkeley.edu  Thu Jun 12 23:24:46 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Thu, 12 Jun 2003 15:24:46 -0700
Subject: [Python-Dev] test_strptime failed
In-Reply-To: <1054850175.24597.27.camel@slothrop.zope.com>
References: <1054850175.24597.27.camel@slothrop.zope.com>
Message-ID: <3EE8FDAE.30605@ocf.berkeley.edu>

Jeremy Hylton wrote:
> I've been running the python tests frequently today, from a checkout I
> did mid-morning.  I just noticed an unexpected failure.  This is with a
> regular build; I'll see if it is repeatable.
> 
> Jeremy
> 
> 
> test test_strptime failed -- Traceback (most recent call last):
>   File "/home/jeremy/src/python/dist/src/Lib/test/test_strptime.py",
> line 203, in test_compile
>     self.failUnless(found, "Matching failed on '%s' using '%s' regex" %
>   File "/home/jeremy/src/python/dist/src/Lib/unittest.py", line 268, in
> failUnless
>     if not expr: raise self.failureException, msg
> AssertionError: Matching failed on 'Thu 05 Jun 2003 05:46:43 PM EDT'
> using
> '(?P<a>Mon|Tue|Wed|Thu|Fri|Sat|Sun)\s*(?P<d>3[0-1]|[1-2]\d|0[1-9]|[1-9]|
> [1-9])\s*(?P<b>Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s*(?P<Y>\d\d\d\d)\s*(?P<I>1[0-2]|0[1-9]|[1-9]):(?P<M>[0-5]\d|\d):(?P<S>6[0-1]|[0-5]\d|\d)\s*(?P<p>AM|PM)\s*EST' regex
> 

Jeremy, are you still getting this failure?  How about anyone else?

-Brett



From cce@clarkevans.com  Thu Jun 12 23:56:45 2003
From: cce@clarkevans.com (Clark C. Evans)
Date: Thu, 12 Jun 2003 22:56:45 +0000
Subject: [Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky 'super' instances)
In-Reply-To: <5.1.1.6.0.20030612115854.0260e100@telecommunity.com>
References: <16E1010E4581B049ABC51D4975CEDB88619A99@UKDCX001.uk.int.atosorigin.com> <5.1.1.6.0.20030612115854.0260e100@telecommunity.com>
Message-ID: <20030612225645.GA20783@doublegemini.com>

Paul,

  The goal of PEP 246 is to create a loose coupling between various
  framework components to facilitate the 'adapter' pattern as described
  in the GOF pattern book.   It is also motivated by Microsoft's
  QueryInterface, which when used intelligently is extremely powerful.

  The primary audience of PEP 246 are component/library developres
  who wish for their components to interoperate between frameworks.
  Unless you are writing components and wish for them to work across,
  say Zope, Twisted, and Webware, using a single code base in a
  managable manner then you may not understand the PEP.   In particular,
  PEP 246 will be successful if your average programmer does not
  even know about adapt!  He simply pluggs component X into framework
  Y and it works... automagically. 

  For example, I have a 'Flow' manager (a generator based cooperative
  multitasking library).   Currently it is dependent upon twisted, 
  however, there are really only two protocols I depend upon:
    (a) wrapping an exception for later delivery, 
    (b) some sort of event loop for scheduling delayed execution.
  With PEP 246 I'd write an interface flow.IFailure and flow.IReactor,
  and provide clean ways for it to work with Twisted.  Then, if some
  other framework wanted to "re-use" my component, it'd be easy, they'd
  simply add a __conform__ to their objects, and __adapt__ my objects.
  This is far more powerful than requiring my code or their code to
  directly know about each other and the interface mechanism that each
  of them uses.    

I hope this helps,

Clark

On Thu, Jun 12, 2003 at 12:48:51PM -0400, Phillip J. Eby wrote:
| At 03:42 PM 6/12/03 +0100, Moore, Paul wrote:
| >From: Phillip J. Eby [mailto:pje@telecommunity.com]
| >> Open protocols solve the chicken and egg problem by allowing one
| >> to make declarations about third-party objects.
| >
| >OK, I've tried to put together a simple example of "what I expect" and
| >I find I can't. I want to continue to write code which "just assumes"
| >that it gets the types it needs - I don't want to explicitly state that
| >I need specific interface types - that feels like type declaration and
| >Java. Your IFile example reinforces that, both in terms of its naming
| >convention, and in the assumption that there *is* a single, usable,
| >"file" protocol. I know it was my example, but I pointed out later in
| >the same message that I really sometimes wanted seekable readline-only
| >files, and other times block read/write (potentially unseekable) files.
| >
| >Expecting library writers to declare interface "classes" for every
| >subtle variation of requirements seems impractical. Expecting the
| >requirements to be *documented* is fine - it's having a concrete class
| >which encapsulates them that I don't see happening - no-one would ever
| >look to see if there was already a "standard" interface which said "I
| >have readline, seek, and tell" - they'd just write a new one. There
| >goes any hope of reuse. (This may be what you see as a "chicken and egg"
| >problem - if so, I see it as a "hopelessly unrealistic expectations"
| >problem instead, because it's never going to happen...)
| 
| Even if it's as simple as saying this:
| 
|     class ReadlineSeekAndTell(Interface):
|         """You must have readline, seek, and tell if you pass this to me"""
|         advise(protocolIsSubsetof=[IFile])
| 
| 
| Or, even more briefly, using Samuele's way:
| 
|     RST = subproto(IFile,['readline','seek','tell'])
| 
| 
| 
| >On the other hand, expecting callers to write stuff to adapt existing
| >classes to the requirements of library routines is (IMHO) a non-issue.
| >I think that's what PEP 246 was getting at in the statement that "The
| >typical Python programmer is an integrator" which you quote. It's
| >common to write
| >
| >    class wrap_source:
| >        def __init__(self, source):
| >            self.source = source
| >        def read(self, n = 1024):
| >            return self.source.get_data(n)
| >
| >    lib_fn(wrap_source(my_source))
| >
| >So PEP 246 is trying to make writing that sort of boilerplate easier
| >(in my view). The *caller* should be calling adapt(), not the callee.
| 
| That depends.  It's common in both Zope and Twisted for framework code to 
| do the Zope or Twisted equivalents of 'adapt()'.  But yes, it is also 
| common to state that some function in effect requires an already adapted 
| object.
| 
| 
| ><snip>
| >Which is appropriate is basically down to which came first, string or
| >file. But both suffer from the problem of putting all the knowledge
| >in one location (and using a type switch as well).
| 
| Right.  That's what the point of the open protocols system is.  The problem 
| is that in every Python interface system I know of (except PyProtocols), 
| you can't declare that package A, protocol X, implies package B, protocol 
| Y, unless you are the *author* of package B's protocol Y.
| 
| But if package A's author used an open protocol to define protocol X, then 
| you can use PyProtocols today to say that it implies package B's protocol 
| Y, as long as protocol Y can be adapted to the declaration API.
| 
| Translation: anybody who defines protocols for their packages today using 
| PyProtocols, will be able to have third parties define adapters to 
| interfaces provided by Zope or Twisted, or that are defined using Zope or 
| Twisted interfaces.
| 
| 
| >The third option, which is the "external registry" allows a *user* of
| >the string and file "libraries" (bear with me here...) to say how he
| >wants to make strings look like files:
| >
| ><snip>
| >So I see PEP 246 as more or less entirely a class based mechanism. It
| >has very little to do with constraining (or even documenting) the
| >types of function parameters.
| 
| PEP 246 specifically said it wasn't tackling that case, however, and I 
| personally don't feel that a singleton of such broad scope is practical; it 
| seems more appropriate to make protocols responsible for their own adapter 
| registries, which is what PyProtocols (and to a lesser extent Twisted) do.
| 
| 
| >Of course, a library writer can define interface classes, and the
| >adaptation mechanism will allow concrete classes to be made to
| >"conform" to those interfaces, but it's not necessary. And given
| >the general apathy of the Python community towards interfaces (at
| >least as far as I see) I don't imagine this being a very popular use
| >pattern.
| 
| When designing PyProtocols I did some research on the type-sig, and other 
| places...  I got the distinct impression that lots of Pythonistas like 
| interfaces, as long as they're abstract base classes.  PyProtocols allows 
| that.  But, a protocol can also be a pure symbol, e.g.:
| 
| import protocols
| 
| myInterface = protocols.Protocol()
| 
| 
| Voila.  There's your interface.  Let the user register what they 
| will.  Sure, it doesn't *document* anything that isn't stated by its name, 
| but that's your users' problem.  ;)  At least they can import 
| 'yourpackage.myInterface' and register adapters now.
| 
| 
| >And describing a PEP 246 style facility in terms of
| >interfaces could be a big turn-off. (This applies strongly to your
| >PyProtocols code - I looked for something like the pep246.register
| >function I suggested above, but I couldn't manage to wade through all
| >the IThis and IThat stuff to find it, if it was there...)
| 
| Unfortunately, I biased the reference documentation towards explaining the 
| architecture and what you need to do to integrate with the framework 
| itself, even though 90% of the actual intended audience of PyProtocols will 
| never need to do anything like that.  In a sense, you could say that the 
| current reference manual is much more of an embedding and extending manual, 
| instead of being the Python tutorial.
| 
| 
| >Once again, I apologise if I've missed your point. But I hope I've
| >explained what I see as the point of PEP 246, and where your proposal
| >is going off in a different direction.
| 
| I understand what you're saying, although I'm not sure how you interpreted 
| PEP 246 that way, when it explicitly states that it *doesn't* cover case 
| "e".  And I didn't diverge from PEP 246 in that respect.  What I 
| effectively said is, "well, let's make it so that case "e" is irrelevant, 
| because there are plenty of __adapt__-capable protocols, and because you 
| can register the relationships between them."  Thus, the solution to case 
| "e" is effectively:
| 
| Don't use built-in types as protocols!
| 
| 
| >But the fact remains, that neither PEP 246 nor PyProtocols has any
| >need to be in the core, or even in the standard library (yet). Wide
| >usage could change that. Usage in something that is destined for the
| >standard library could, too, but that one could go the other way (the
| >"something" gets rejected because it depends on PEP246/PyProtocols).
| 
| Right, that was why I was asking.
| 
| 
| >PS This is *way* off-topic for python-dev by now. I suggest that we
| >   leave things here. I don't have anything else worth adding...
| 
| I suppose we could always resurrect the types-sig....  Although, as Tim 
| Peters has frequently suggested, nothing ends discussion more quickly than 
| having an implementation available.  :)
| 
| 
| _______________________________________________
| Python-Dev mailing list
| Python-Dev@python.org
| http://mail.python.org/mailman/listinfo/python-dev


From greg@cosc.canterbury.ac.nz  Fri Jun 13 00:48:01 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 13 Jun 2003 11:48:01 +1200 (NZST)
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <2mptlj615f.fsf@starship.python.net>
Message-ID: <200306122348.h5CNm1C15944@oma.cosc.canterbury.ac.nz>

> Those are fields in the thread state, not globals, IIRC.

That's true. The point is that they're C variables, not
Python variables, so they won't interfere with the goal
of eliminating the sys.exc_xxx.

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


From greg@cosc.canterbury.ac.nz  Fri Jun 13 01:15:27 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 13 Jun 2003 12:15:27 +1200 (NZST)
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <3EE876CA.3080903@livinglogic.de>
Message-ID: <200306130015.h5D0FRh16022@oma.cosc.canterbury.ac.nz>

> > I'm not keen on the name "cause" for the start of the exception chain.
> > I'm not sure I have a better suggestion.  Maybe "antecedent"? ;/
> 
> "reason"?

That doesn't seem any better than "cause". Maybe "precursor"?

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


From greg@cosc.canterbury.ac.nz  Fri Jun 13 01:31:12 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 13 Jun 2003 12:31:12 +1200 (NZST)
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121348.h5CDmbH11196@odiug.zope.com>
Message-ID: <200306130031.h5D0VCh16042@oma.cosc.canterbury.ac.nz>

Guido:

> There's a lot of C code out there that catches e.g. AttributeError and
> replaces it with a more specific error (e.g. BifurcationError("can't
> bifurcate the sploorg") replacing AttributeError("__bifurcate__").  I
> think this would cause end user confusion.

But that is a different case. As I understand it, chaining would only
occur if a second exception was raised *before* the current exception
was caught -- e.g. if there's a bug in a piece of code in a finally
block that's being executed while unwinding to find an exception
handler.

In the case you're talking about, the AttributeError has been caught
by the time the BifurcationError is raised, so there would be no
chaining, and thus the traceback output would be the same regardless
of whether chained tracebacks were printed or not.

As for whether chained tracebacks should be printed when they occur,
I'll have to think about that. If they are, probably the one for the
most recently raised exception should be printed last, since one tends
to look at the bottom of the traceback first to find the cause of the
immediate problem (I do, at least).

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


From guido@python.org  Fri Jun 13 01:43:09 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 20:43:09 -0400
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: "Your message of Fri, 13 Jun 2003 00:22:08 +0200."
 <3EE8FD10.2060108@lemburg.com>
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz>
 <200306121344.h5CDiUi11167@odiug.zope.com> <3EE8FD10.2060108@lemburg.com>
Message-ID: <200306130043.h5D0h9m30149@pcp02138704pcs.reston01.va.comcast.net>

> Very close is still not good enough :-)
> 
> I can't really believe that you're designing protocols that have
> to call unknown factory functions to see whether they do something
> particular or not.
> 
> If you really happen to have a need for this, why can't you
> introduce factory functions which take care of your particular
> use case ? I don't think it's common enough to risk accidental
> progamming errors in other user's code.

Marc, you haven't shown why it's so bad either, so please shut up.

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


From guido@python.org  Fri Jun 13 01:52:38 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 12 Jun 2003 20:52:38 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: "Your message of Fri, 13 Jun 2003 12:31:12 +1200."
 <200306130031.h5D0VCh16042@oma.cosc.canterbury.ac.nz>
References: <200306130031.h5D0VCh16042@oma.cosc.canterbury.ac.nz>
Message-ID: <200306130052.h5D0qcf30211@pcp02138704pcs.reston01.va.comcast.net>

> > There's a lot of C code out there that catches e.g. AttributeError and
> > replaces it with a more specific error (e.g. BifurcationError("can't
> > bifurcate the sploorg") replacing AttributeError("__bifurcate__").  I
> > think this would cause end user confusion.
> 
> But that is a different case. As I understand it, chaining would only
> occur if a second exception was raised *before* the current exception
> was caught -- e.g. if there's a bug in a piece of code in a finally
> block that's being executed while unwinding to find an exception
> handler.

Interesting..  I had never even thought of this case.  I thought
chaining was specifically when catching an exception and raising
another in its place.

To the people who came up with the idea, which is it?

(I can see an argument for both cases; maybe they should be supported
using different system attributes on the exception object?)

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


From greg@cosc.canterbury.ac.nz  Fri Jun 13 01:53:14 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 13 Jun 2003 12:53:14 +1200 (NZST)
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306121827.h5CIRm113088@odiug.zope.com>
Message-ID: <200306130053.h5D0rEs16116@oma.cosc.canterbury.ac.nz>

> Right, this could work (even though in 2.3, the module type is no
> longer subclassable).

Oh, no! Why not? There'd better be a REALLY good reason
for this, because you've just killed one of the ideas
I was looking forward to trying out.

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


From greg@cosc.canterbury.ac.nz  Fri Jun 13 02:08:48 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 13 Jun 2003 13:08:48 +1200 (NZST)
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306130052.h5D0qcf30211@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <200306130108.h5D18mv16148@oma.cosc.canterbury.ac.nz>

Guido:

> Interesting..  I had never even thought of this case.  I thought
> chaining was specifically when catching an exception and raising
> another in its place.

> (I can see an argument for both cases; maybe they should be supported
> using different system attributes on the exception object?)

If you're explicitly catching and replacing an exception, and
you want chaining, you can do it yourself. System support is
really only needed for the cases where you can't do it yourself.

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


From pje@telecommunity.com  Fri Jun 13 03:43:04 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jun 2003 22:43:04 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306130053.h5D0rEs16116@oma.cosc.canterbury.ac.nz>
References: <200306121827.h5CIRm113088@odiug.zope.com>
Message-ID: <5.1.0.14.0.20030612224214.04260a30@mail.telecommunity.com>

At 12:53 PM 6/13/03 +1200, Greg Ewing wrote:
> > Right, this could work (even though in 2.3, the module type is no
> > longer subclassable).
>
>Oh, no! Why not? There'd better be a REALLY good reason
>for this, because you've just killed one of the ideas
>I was looking forward to trying out.

Don't panic.  It's still subclassable as of 2.3b1.  It's *modules* that you 
can't subclass.



From greg@cosc.canterbury.ac.nz  Fri Jun 13 04:52:39 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 13 Jun 2003 15:52:39 +1200 (NZST)
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <5.1.0.14.0.20030612224214.04260a30@mail.telecommunity.com>
Message-ID: <200306130352.h5D3qda17371@oma.cosc.canterbury.ac.nz>

"Phillip J. Eby" <pje@telecommunity.com>:

> Don't panic.  It's still subclassable as of 2.3b1.  It's *modules*
> that you can't subclass.

I'm very relieved to hear that, thanks!

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


From kbk@shore.net  Fri Jun 13 05:59:34 2003
From: kbk@shore.net (Kurt B. Kaiser)
Date: Fri, 13 Jun 2003 00:59:34 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306122058.h5CKwd515011@odiug.zope.com> (Guido van Rossum's
 message of "Thu, 12 Jun 2003 16:58:39 -0400")
References: <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl>
 <200306122058.h5CKwd515011@odiug.zope.com>
Message-ID: <m3n0gmzi6h.fsf@float.attbi.com>

Guido van Rossum <guido@python.org> writes:
  [Jack Jansen]
>> +1 on the functionality. But: if it's so small why not simply put it in 
>> sys?
>
> Hm, that's not bad.  It should be called sys.interrupt_main() then.

Works for me!

http://sourceforge.net/tracker/index.php?func=detail&aid=753733&group_id=5470&atid=305470

__
KBK


From python@rcn.com  Fri Jun 13 05:50:53 2003
From: python@rcn.com (Raymond Hettinger)
Date: Fri, 13 Jun 2003 00:50:53 -0400
Subject: [Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky 'super' instances)
References: <16E1010E4581B049ABC51D4975CEDB88619A99@UKDCX001.uk.int.atosorigin.com> <5.1.1.6.0.20030612115854.0260e100@telecommunity.com> <20030612225645.GA20783@doublegemini.com>
Message-ID: <000001c3316d$81d93d40$125ffea9@oemcomputer>

Clark C. Evans

>   The goal of PEP 246 is to create a loose coupling between various
>   framework components to facilitate the 'adapter' pattern as described
>   in the GOF pattern book. 

The adapter pattern is much simpler idea of writing a wrapper and 
possibly using multiple inheritance to link an implementation to a
foreign interface.

PEP 246 is a higher level protocol for seeking and applying
pre-existing wrappers.

Of course you know that, but the summary above tends to 
equate 246 with the GOF adapter pattern.


>   The primary audience of PEP 246 are component/library developres
>   who wish for their components to interoperate between frameworks.

This is why I don't think adapt() should be a builtin.  
adapt.adapt() is not any harder to call than random.random()
or glob.glob().


>   Unless you are writing components and wish for them to work across,
>   say Zope, Twisted, and Webware, using a single code base in a
>   managable manner then you may not understand the PEP.   In particular,
>   PEP 246 will be successful if your average programmer does not
>   even know about adapt!  He simply pluggs component X into framework
>   Y and it works... automagically. 

Yep.  All it takes is one user to contribute code to support a protocol.
My expectation is that the adapter code will (for the most part) be 
contributed by a sophisticated component user rather than the original
supplier of the component.  After all, if the supplier thought the
foreign protocol was important, they would have supplied it in
the first place.  The nice thing about 246 is that the adapter code
can be contributed without altering the original component code
(OCP: open for extension, closed for modification).

I don't see any significant downside to 246.  The code is simple
enough.  It is useful in at least some cases and provides some
support for interoperability.  I don't think it makes writing
adapters any easier -- it does nothing to mitigate the problem
of widely differing protocols with different underlying assumptions.
Getting complete, bug free general purpose adoption will still
remain a hard problem.  Cie le vie.

So, my questions is whether there is any reason not to adopt 246
right away?  AFAICT, there is no competing proposal and nothing
that would be harmed by adoption.  What's all the fuss about?


Raymond Hettinger



#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################


From Raymond Hettinger" <python@rcn.com  Fri Jun 13 08:03:09 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Fri, 13 Jun 2003 03:03:09 -0400
Subject: [Python-Dev] Sporadic test failures in Lib/test/test_mimetools.py
Message-ID: <002a01c33179$d96fea20$125ffea9@oemcomputer>

This test fails about one every ten tries on my WinMe box
and I won't be able to examine it for a few days:


C:\py23\Lib\test>python regrtest.py test_mimetools
test_mimetools
1 test OK.

C:\py23\Lib\test>python regrtest.py test_mimetools
test_mimetools
test test_mimetools failed -- Traceback (most recent call last):
  File "C:\PY23\lib\test\test_mimetools.py", line 31, in test_boundary
    self.assert_(nb not in s)
  File "C:\PY23\lib\unittest.py", line 268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError

1 test failed:
    test_mimetools


Raymond Hettinger


From mal@lemburg.com  Fri Jun 13 08:40:50 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 13 Jun 2003 09:40:50 +0200
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: <200306130043.h5D0h9m30149@pcp02138704pcs.reston01.va.comcast.net>
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz> <200306121344.h5CDiUi11167@odiug.zope.com> <3EE8FD10.2060108@lemburg.com> <200306130043.h5D0h9m30149@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <3EE98002.2040205@lemburg.com>

Guido van Rossum wrote:
>>Very close is still not good enough :-)
>>
>>I can't really believe that you're designing protocols that have
>>to call unknown factory functions to see whether they do something
>>particular or not.
>>
>>If you really happen to have a need for this, why can't you
>>introduce factory functions which take care of your particular
>>use case ? I don't think it's common enough to risk accidental
>>progamming errors in other user's code.
> 
> Marc, you haven't shown why it's so bad either, so please shut up.

I beg your pardon: Just look at the last sentence in my reply. It is
you that hasn't shown a single qualified use case for this "feature".
You also haven't shown why the defaults you have chosen were picked
and what the reasoning was.

On other occasions you have always been picking on the usefulness of
raising excpetions instead of going with defaults. Here you are doing
the exact opposite and the only argument I've heard so far is that
you need to call constructors without argument in Zope3 for some
reason which you also haven't explained.

If there's no use case for this, then why add a case for possible
programming errors ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 13 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        11 days left



From aleaxit@yahoo.com  Fri Jun 13 09:14:08 2003
From: aleaxit@yahoo.com (Alex Martelli)
Date: Fri, 13 Jun 2003 10:14:08 +0200
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins] python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: <3EE98002.2040205@lemburg.com>
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz> <200306130043.h5D0h9m30149@pcp02138704pcs.reston01.va.comcast.net> <3EE98002.2040205@lemburg.com>
Message-ID: <200306131014.08761.aleaxit@yahoo.com>

On Friday 13 June 2003 09:40 am, M.-A. Lemburg wrote:
   ...
> >>If you really happen to have a need for this, why can't you
> >>introduce factory functions which take care of your particular
> >>use case ? I don't think it's common enough to risk accidental
> >>progamming errors in other user's code.
> >
> > Marc, you haven't shown why it's so bad either, so please shut up.
>
> I beg your pardon: Just look at the last sentence in my reply. It is
> you that hasn't shown a single qualified use case for this "feature".
> You also haven't shown why the defaults you have chosen were picked
> and what the reasoning was.

It appears to me that both the pluses and minuses for this design choice
are so small as not to justify the intensity of the debate (but I may be
missing some subtext).  As long as the behavior of such built-in types
as str, int, long, bool, float &c is consistent -- either all of them can be
called without arguments (each returning a "canonical 'zero' instance" of
the respective type), or none of them can -- I'd be (abstractly) happy.  As
it happens some of them had this minor feature at least as far back as
2.2.2 (earlier I think) so it seems obvious to me that it shouldn't be taken
away in 2.3 (what a gratuitous incompatibility that would be!), and that the
debate is purely theoretical.

As for use cases -- I have not had one in real life in Python (so far), and
indeed if any of the built-in types didn't respect the rule I believe no use
case could present itself.  I did have uses for a very similar feature of C++
types (in C++ templates) and I did note Andrew Koenig speaking up on
this thread about the same thing.  The parallels are not exact, I think.  One
example is making a "canonical type-matching representation" of e.g. a
tuple:
    canonical_tuple = tuple( [ type(x)() for x in original_tuple ] )
to be used e.g. as a dictionary key for multiple dispatch based on types.
In Python, you have some alternatives to this approach, e.g. relying on
the fact that types are first-class objects:
    types_tuple = tuple( [ type(x) for x in original_tuple ] )

There may still be advantages in using the "tuple of typical instances"
rather than the tuple of types -- minor advantages, to be sure, but then
the "error risk" that seems to be the only disadvantage to offset it is
also quite minor in itself.  For example, consider:

>>> original_tuple = (1, 2.0, 3L, '4', u'5', False)
>>> canonical_tuple = tuple([type(x)() for x in original_tuple])
>>> types_tuple = tuple([type(x) for x in original_tuple])
>>> pick_can = pickle.dumps(canonical_tuple, 2)
>>> pick_typ = pickle.dumps(types_tuple, 2)
>>> len(pick_can)
32
>>> len(pick_typ)
129
>>>

Pickling the canonical-tuple rather than the types-tuple saves about 3/4
the space.  Roughly similar ratios can be seen if what one wants is a
readable string representation of the canonical or types tuple:

>>> len(str(canonical_tuple))
28
>>> len(str(types_tuple))
92
>>>


So, I think some use cases do exist for the general-ish rule "whenever
it makes some sense, a type is callable without arguments and when so
called returns the one instance of that type which evaluates to false".

That 'false instance' then becomes the "default, or rather, canonical"
instance of the type, and can be used to 'stand for the type' in cases such
as the above tuples.  Given any instance of the unknown type the canonical
instance can be obtained as type(x)().

Other uses involve e.g. simplifying a generator (or other callable) that takes 
a factory function and may call it without arguments: in some cases this
will let you pass the type object directly, e.g. int, rather than making up a
simple factory such as lambda: 0.  Tiny and marginal advantages, to be
sure.  But the claimed disadvantage also looks tiny and marginal to me.


Alex



From mal@lemburg.com  Fri Jun 13 09:34:49 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 13 Jun 2003 10:34:49 +0200
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: <200306131014.08761.aleaxit@yahoo.com>
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz>	<200306130043.h5D0h9m30149@pcp02138704pcs.reston01.va.comcast.net>	<3EE98002.2040205@lemburg.com> <200306131014.08761.aleaxit@yahoo.com>
Message-ID: <3EE98CA9.3020001@lemburg.com>

Alex Martelli wrote:
> On Friday 13 June 2003 09:40 am, M.-A. Lemburg wrote:
>    ...
>>>>If you really happen to have a need for this, why can't you
>>>>introduce factory functions which take care of your particular
>>>>use case ? I don't think it's common enough to risk accidental
>>>>progamming errors in other user's code.
>>>
>>>Marc, you haven't shown why it's so bad either, so please shut up.
>>
>>I beg your pardon: Just look at the last sentence in my reply. It is
>>you that hasn't shown a single qualified use case for this "feature".
>>You also haven't shown why the defaults you have chosen were picked
>>and what the reasoning was.
> 
> It appears to me that both the pluses and minuses for this design choice
> are so small as not to justify the intensity of the debate (but I may be
> missing some subtext).  As long as the behavior of such built-in types
> as str, int, long, bool, float &c is consistent -- either all of them can be
> called without arguments (each returning a "canonical 'zero' instance" of
> the respective type), or none of them can -- I'd be (abstractly) happy.  As
> it happens some of them had this minor feature at least as far back as
> 2.2.2 (earlier I think) so it seems obvious to me that it shouldn't be taken
> away in 2.3 (what a gratuitous incompatibility that would be!), and that the
> debate is purely theoretical.
> 
> As for use cases -- I have not had one in real life in Python (so far), and
> indeed if any of the built-in types didn't respect the rule I believe no use
> case could present itself.  I did have uses for a very similar feature of C++
> types (in C++ templates) and I did note Andrew Koenig speaking up on
> this thread about the same thing.  The parallels are not exact, I think.  One
> example is making a "canonical type-matching representation" of e.g. a
> tuple:
>     canonical_tuple = tuple( [ type(x)() for x in original_tuple ] )
> to be used e.g. as a dictionary key for multiple dispatch based on types.
> In Python, you have some alternatives to this approach, e.g. relying on
> the fact that types are first-class objects:
>     types_tuple = tuple( [ type(x) for x in original_tuple ] )
> 
> There may still be advantages in using the "tuple of typical instances"
> rather than the tuple of types -- minor advantages, to be sure, but then
> the "error risk" that seems to be the only disadvantage to offset it is
> also quite minor in itself.  For example, consider:
> 
> 
>>>>original_tuple = (1, 2.0, 3L, '4', u'5', False)
>>>>canonical_tuple = tuple([type(x)() for x in original_tuple])
>>>>types_tuple = tuple([type(x) for x in original_tuple])
>>>>pick_can = pickle.dumps(canonical_tuple, 2)
>>>>pick_typ = pickle.dumps(types_tuple, 2)
>>>>len(pick_can)
> 
> 32
> 
>>>>len(pick_typ)
> 
> 129
> 
> 
> Pickling the canonical-tuple rather than the types-tuple saves about 3/4
> the space.  Roughly similar ratios can be seen if what one wants is a
> readable string representation of the canonical or types tuple:
> 
> 
>>>>len(str(canonical_tuple))
> 
> 28
> 
>>>>len(str(types_tuple))
> 
> 92
> 
> 
> 
> So, I think some use cases do exist for the general-ish rule "whenever
> it makes some sense, a type is callable without arguments and when so
> called returns the one instance of that type which evaluates to false".
> 
> That 'false instance' then becomes the "default, or rather, canonical"
> instance of the type, and can be used to 'stand for the type' in cases such
> as the above tuples.  Given any instance of the unknown type the canonical
> instance can be obtained as type(x)().
> 
> Other uses involve e.g. simplifying a generator (or other callable) that takes 
> a factory function and may call it without arguments: in some cases this
> will let you pass the type object directly, e.g. int, rather than making up a
> simple factory such as lambda: 0.  Tiny and marginal advantages, to be
> sure.  But the claimed disadvantage also looks tiny and marginal to me.

Thanks, Alex. At least you're giving a reasonable analysis of the
idea behind the default constructor values.

I can see your point and given that we can't revert to the non-default
value due to the fact that e.g. int() and str() already behave like
this in Python2.2, I withdraw my request. No idea, why Guido couldn't
have come up with a similar explanation or a simple "hey, at the time
I thought it was better this way". That ignorace probably caused the
heat on my side, not the subject itself.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 13 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        11 days left



From andersjm@dancontrol.dk  Fri Jun 13 09:43:24 2003
From: andersjm@dancontrol.dk (Anders J. Munch)
Date: Fri, 13 Jun 2003 10:43:24 +0200
Subject: [Python-Dev] The proliferation of simple lowercase words in builtins (was: Default constructor values)
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz> <200306121344.h5CDiUi11167@odiug.zope.com> <3EE8FD10.2060108@lemburg.com> <200306130043.h5D0h9m30149@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <006b01c33187$da966060$f901a8c0@hirsevej.dk>

Hi all, this is my first post to python-dev.

I see this a lot in replies to newbies on c.l.py: The newbie has used
'open' or 'list' as a variable name, and is warned not to do that
because it shadows the builtin by the same name.

But dir(__builtins__) tells me that it's unrealistic to expect
pythoneers to avoid shadowing the builtins; there are simply too many
builtins with names that are lowercase dictionary words.

I could find plenty of examples from my own code, or from the standard
library, e.g. in code.py:
    list = traceback.format_exception_only(type, value)

Now scoping means that this still works, but error reporting is
affected.  By Murphy's law, someone is at sometime going to
accidentally call a builtin when a user-defined variable was intended.

    weekdays = list()
    def list():
        """lists weekdays"""
        return ['Mon', 'Tue', 'Wed', 'worn out already, see ya next week']

To aid in error reporting I think builtins should, all else equal, be
strict about their arguments -- the fewer valid argument combinations,
the better the chance that a mistaken use is flagged right away.

int(), str() and list() I don't understand -- lambda:0, lambda:'' and
lambda:[] communicate intent better than int, str and list.

- Anders




From just@letterror.com  Fri Jun 13 10:03:36 2003
From: just@letterror.com (Just van Rossum)
Date: Fri, 13 Jun 2003 11:03:36 +0200
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <Pine.LNX.4.44.0306121653130.14462-100000@penguin.theopalgroup.com>
Message-ID: <r01050400-1026-F2CAD5569D7D11D7B4B1003065D5E7E4@[10.0.0.23]>

Kevin Jacobs wrote:

> On Thu, 12 Jun 2003, Guido van Rossum wrote:
> > > In that past, there have been a few times where it would have
> > > been very convenient to terminate/signal another thread by
> > > posting an exception to it.  Using KeyboardInterrupt to do so is
> > > okay, although it seems like something of a kludge.
> > 
> > This gets into the general discussion about whether threads should
> > be stoppable.
> 
> True -- I am of the opinion that threads should be cooperatively
> stoppable, but not preemptively stoppable, if that makes sense. 
> Asynchronous exceptions are the ideal way of implementing this, since
> the main interpreter loop is essentially already instrumented to
> handle them.

Exactly.

> > Also, this mechanism can *only* interrupt the main thread.  (That's
> > even true of the more generalized version you were thinking of.)

I wonder if that limitation would be liftable? Anybody interested in
persuing this with me?

> Ah.. that sounds familiar.  I knew there was a reason I didn't pursue
> this avenue farther last time I poked through that code.

Same here. The code that checks for interrupts explicitly does nothing
when called from a thread that's not the main thread.

Naming: putting this into main sounds just right, but I would suggest to
call it sys.interrupt() instead of sys.interrupt_main(). That way *if*
we ever add the possibility to interrupt a non-main thread,
sys.interrupt() could grow an optional argument specifying the thread.

Just


From aleaxit@yahoo.com  Fri Jun 13 10:11:58 2003
From: aleaxit@yahoo.com (Alex Martelli)
Date: Fri, 13 Jun 2003 11:11:58 +0200
Subject: [Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky 'super' instances)
In-Reply-To: <5.1.1.6.0.20030612115854.0260e100@telecommunity.com>
References: <5.1.1.6.0.20030612115854.0260e100@telecommunity.com>
Message-ID: <200306131111.58636.aleaxit@yahoo.com>

On Thursday 12 June 2003 06:48 pm, Phillip J. Eby wrote:
   ...
> effectively said is, "well, let's make it so that case "e" is irrelevant,
> because there are plenty of __adapt__-capable protocols, and because you
> can register the relationships between them."  Thus, the solution to case
> "e" is effectively:
>
> Don't use built-in types as protocols!

Speaking as PEP 246's co-author and original champion of "case [e]", I think
you've hit the nail on the head.  Yes, singling out protocols as the "new kid
on the block" and giving each protocol the responsibility of handling the
registry of its adapters definitely strikes me as the right architecture, 
better than the vaguely defined one I had in mind (too vague to put in the
PEP) which as you say / imply elsewhere would necessarily end up with a
major case of chronical singletonitis.  I'm not sure about some other details
of PyProtocols (guess I need to study the whole package very, very
carefully) but this general architectural idea gets a wholehearted +1 from me.


Alex



From jacobs@penguin.theopalgroup.com  Fri Jun 13 11:27:27 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Fri, 13 Jun 2003 06:27:27 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <r01050400-1026-F2CAD5569D7D11D7B4B1003065D5E7E4@[10.0.0.23]>
Message-ID: <Pine.LNX.4.44.0306130616120.18906-100000@penguin.theopalgroup.com>

On Fri, 13 Jun 2003, Just van Rossum wrote:
> Kevin Jacobs wrote:
> > > Also, this mechanism can *only* interrupt the main thread.  (That's
> > > even true of the more generalized version you were thinking of.)
> 
> I wonder if that limitation would be liftable? Anybody interested in
> persuing this with me?

Sure!  I've also got several complex applications to use as test cases that
can be adapted to take advantage of threaded interrupts.

> > Ah.. that sounds familiar.  I knew there was a reason I didn't pursue
> > this avenue farther last time I poked through that code.
> 
> Same here. The code that checks for interrupts explicitly does nothing
> when called from a thread that's not the main thread.

That chunk of code is very problematic.  Some platforms/threading libraries
will deliver a SIGINT to all threads, which can abort many system calls that
are not trivially restarted/restartable.  To deliver a KeyboardInterrupt
only to the main thread is problematic, since the other threads may
misinterpret the failure as something else (EOF, fatal error, or worse,
operation succeeded).

I understand the desire to smooth over platform differences in Python, but
I'm not sure that this one (signal delivery policy to threads) is a good
idea.  In fact, I'll try to find a real-world case where this kind of error
occurs.

> Naming: putting this into main sounds just right, but I would suggest to
> call it sys.interrupt() instead of sys.interrupt_main(). That way *if*
> we ever add the possibility to interrupt a non-main thread,
> sys.interrupt() could grow an optional argument specifying the thread.

I Agree.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From mcherm@mcherm.com  Fri Jun 13 12:44:37 2003
From: mcherm@mcherm.com (Michael Chermside)
Date: Fri, 13 Jun 2003 04:44:37 -0700
Subject: [Python-Dev] RE: Sneaky 'super' instances
Message-ID: <1055504677.3ee9b9259c6d9@mcherm.com>

Phillip J. Eby writes:
> In effect, my question is, "Should I expend the extra effort to develop the 
> documentation tool in such a way that it could easily be distributed with 
> the standard library?"  And, since the tool would have to depend on 
> PyProtocols, this means that (in effect) PyProtocols would have to be 
> accepted for the standard library.

_IF_ PyProtocols turned out to be useful and popular, then it would
definitely want to become part of the standard library. The whole idea
behind writing it is to try and beat the chicken-egg-problem by
getting it in use somewhere. If you think it will be useful (and you
wouldn't waste time writing it if you didn't think so) then plan for
success and write it so it can be in the standard library.

The documentation tool itself is another question. I, myself, don't
feel a real need for this, but perhaps others do.

-- Michael Chermside



From ajp@eutechnyx.com  Fri Jun 13 12:51:04 2003
From: ajp@eutechnyx.com (Andrew Perella)
Date: Fri, 13 Jun 2003 12:51:04 +0100
Subject: [Python-Dev] porting problems
Message-ID: <MOELJIPGEEHBHCIFENHCCEFJCCAA.ajp@eutechnyx.com>

Problem 1:
I have compiled python2.2.3c1 for the xbox and the gamecube. When I import a
large module (generated by swig) the xbox version takes 6MB whilst the
gamecube takes 1MB. This is despite using the same custom malloc replacement
code. This problem occurrs whenever the python module being imported gets
bigger than a few thousand lines long. I do not know why the versions do not
behave identically as they both are using a near identical hand generated
pyconfig.h.

Problem 2:
  What d o I need to do to get errors on import etc to show up in my own
custom error printing routines. t the moment I cannot find them unless I am
using the very high python/c interface functions. (In this case I can set
stderr to a custom class and everything works fine)

Any ideas as to what the problems are?
Regards
Andrew


Dr Andrew Perella
Programming Manager
ajp@eutechnyx.com

Eutechnyx Limited is a Deloitte & Touche Fast 50 and a Sunday Times Tech
Track 100 company.

Eutechnyx Limited
Metro Centre East Business Park
Gateshead
Tyne & Wear
NE11 9HU
UK
Phone: +44 (0) 191 460 60 60
Fax: +44 (0) 191 460 22 66
www.eutechnyx.com







_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law. 

This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. 

www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322


From guido@python.org  Fri Jun 13 13:24:07 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 08:24:07 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: "Your message of Fri, 13 Jun 2003 00:59:34 EDT."
 <m3n0gmzi6h.fsf@float.attbi.com>
References: <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl>
 <200306122058.h5CKwd515011@odiug.zope.com> <m3n0gmzi6h.fsf@float.attbi.com>
Message-ID: <200306131224.h5DCO7Q31067@pcp02138704pcs.reston01.va.comcast.net>

> > Hm, that's not bad.  It should be called sys.interrupt_main() then.
> 
> Works for me!
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=753733&group_id=5470&atid=305470

Hm, but since this only makes sense if you have threads, shouldn't it
be in the thread extension module?  Also, you forgot the patch to
idlelib/run.py. :-)

If this makes sense to you, just check it in.

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


From pje@telecommunity.com  Fri Jun 13 13:19:59 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Fri, 13 Jun 2003 08:19:59 -0400
Subject: [Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky
 'super' instances)
In-Reply-To: <000001c3316d$81d93d40$125ffea9@oemcomputer>
References: <16E1010E4581B049ABC51D4975CEDB88619A99@UKDCX001.uk.int.atosorigin.com>
 <5.1.1.6.0.20030612115854.0260e100@telecommunity.com>
 <20030612225645.GA20783@doublegemini.com>
Message-ID: <5.1.0.14.0.20030613075824.020c2d80@mail.telecommunity.com>

At 12:50 AM 6/13/03 -0400, Raymond Hettinger wrote:

>So, my questions is whether there is any reason not to adopt 246
>right away?  AFAICT, there is no competing proposal and nothing
>that would be harmed by adoption.  What's all the fuss about?

Guido has said (and I agree) that if Python includes adapt(), then the 
Python standard library should use it.  However, using it requires that the 
standard library have some standard way at least for it) of defining what a 
"protocol" is.  And that's where the holdup is, because Guido is not yet 
decided about what kind of interfaces or protocols Python should have, and 
he won't be until he's had enough experience with some of the 
approaches.  He's said he doesn't think Zope-style interfaces are going to 
be the way he wants to go, and that something more ABC-like (Abstract Base 
Class) would be preferable.

PyProtocols was my attempt to show that a PEP 246 mechanism can actually be 
pretty agnostic about what kind of interface objects are used, just like 
the '+' operator is agnostic about what object types it's used with.

However, as I've realized from this thread, PyProtocols still doesn't 
actually solve the real issue for Guido: even though PyProtocols doesn't 
care about what kind of interfaces are used, Guido *still* has to decide 
what kind the standard library should use, and I've only *added* another 
approach for him to evaluate!

Ah well.  :)  On the bright side, I think PyProtocols can alleviate *one* 
of his concerns, which was that having a Python-included interface type 
would make other interface types (e.g. Zope interfaces) "second-class 
citizens".  That is, I've demonstrated that it is possible to have a 
"protocol protocol", thus allowing different protocol or interface types to 
exist, even if they have no implementation in common (e.g. Twisted, Zope, 
and PyProtocols).

At this point, though, I don't see any reason to rush PEP 246 into the 
standard library, since there is now a packaged distribution that will 
presumably become a de facto standard for anybody who wants to use PEP 246, 
as it's the only PEP 246 implementation that you can use "out of the box" 
without having to write __conform__ or __adapt__ methods.

The only reason I even brought up the question here, was in relation to the 
adaptation-based documentation toolkit that I intend to write.



From guido@python.org  Fri Jun 13 13:30:19 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 08:30:19 -0400
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: "Your message of Fri, 13 Jun 2003 09:40:50 +0200."
 <3EE98002.2040205@lemburg.com>
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz>
 <200306121344.h5CDiUi11167@odiug.zope.com> <3EE8FD10.2060108@lemburg.com>
 <200306130043.h5D0h9m30149@pcp02138704pcs.reston01.va.comcast.net>
 <3EE98002.2040205@lemburg.com>
Message-ID: <200306131230.h5DCUJS31094@pcp02138704pcs.reston01.va.comcast.net>

> >>If you really happen to have a need for this, why can't you
> >>introduce factory functions which take care of your particular
> >>use case ? I don't think it's common enough to risk accidental
> >>progamming errors in other user's code.
> > 
> > Marc, you haven't shown why it's so bad either, so please shut up.
> 
> I beg your pardon: Just look at the last sentence in my reply. It is
> you that hasn't shown a single qualified use case for this "feature".
> You also haven't shown why the defaults you have chosen were picked
> and what the reasoning was.

To the contrary, I explained my reasons, but you didn't think they
were important.  Similarly, I don't believe you have shown that there
*is* a risk of accidental errors (you haven't shown me a c.l.py
conversation where this caused confusion, despite it being in Python
2.2 since it was released in 2001).

So it's a stalemate.  I can't change it even if I wanted (which I
don't) because of backwards compatibility.  We could change bool() back
but now consistency with the others feels more important to me.

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


From just@letterror.com  Fri Jun 13 13:26:52 2003
From: just@letterror.com (Just van Rossum)
Date: Fri, 13 Jun 2003 14:26:52 +0200
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <Pine.LNX.4.44.0306130616120.18906-100000@penguin.theopalgroup.com>
Message-ID: <r01050400-1026-525760AE9D9A11D7B4B1003065D5E7E4@[10.0.0.23]>

Kevin Jacobs wrote:

> > > Ah.. that sounds familiar.  I knew there was a reason I didn't
> > > pursue this avenue farther last time I poked through that code.
> > 
> > Same here. The code that checks for interrupts explicitly does
> > nothing when called from a thread that's not the main thread.
> 
> That chunk of code is very problematic.  Some platforms/threading
> libraries will deliver a SIGINT to all threads, which can abort many
> system calls that are not trivially restarted/restartable.  To
> deliver a KeyboardInterrupt only to the main thread is problematic,
> since the other threads may misinterpret the failure as something
> else (EOF, fatal error, or worse, operation succeeded).
> 
> I understand the desire to smooth over platform differences in
> Python, but I'm not sure that this one (signal delivery policy to
> threads) is a good idea.  In fact, I'll try to find a real-world case
> where this kind of error occurs.

While the signal module is used in the implementation of
PyErr_SetInterrupt(), I don't think signals play a part when
interrupting threads: all that needs to be done is add a pending call
that sets KeyboardInterrupt and returns -1.

The problem is that the pending calls mechanism is for the main thread
onle, and involves globals (mainly ceval.c's 'pendingcalls' and
'things_to_do'). So the first thing we'd need to look into is moving
those globals to the PyThreadState struct (or to PyThreadState's dict
object).

(Btw. whatever we do, it won't interrupt blocking system calls, but I
think that's fine. sys.interrupt() won't interrupt these either.)

Just


From guido@python.org  Fri Jun 13 13:40:02 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 08:40:02 -0400
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: "Your message of Fri, 13 Jun 2003 10:14:08 +0200."
 <200306131014.08761.aleaxit@yahoo.com>
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz>
 <200306130043.h5D0h9m30149@pcp02138704pcs.reston01.va.comcast.net>
 <3EE98002.2040205@lemburg.com> <200306131014.08761.aleaxit@yahoo.com>
Message-ID: <200306131240.h5DCe2931140@pcp02138704pcs.reston01.va.comcast.net>

> So, I think some use cases do exist for the general-ish rule
> "whenever it makes some sense, a type is callable without arguments
> and when so called returns the one instance of that type which
> evaluates to false".

Right.  The first half of this is probably why I did it in the first
place: I'd like all types to have a constructor callable with no
arguments, and whenever it's possible and reasonable to construct a
valid instance by providing suitable default constructor arguments,
this should be so.  The second half is a pretty weak additional
requirement that I think Raymond H made up when he fixed the bool()
constructor; it just makes sense for containers and sequences to
construct an empty one and for numbers to use zero.

BTW, for your amusement, here's a (theoretical) use case: sometimes
you write some polymorphic code that takes a sequence but would like
to use an empty sequence of the same type.  You can do a[:0] to create
one, but some sequence types (e.g. Numeric arrays) have funny slice
semantics.  Calling type(a)() would make perfect sense for creating an
empty of the same type.  Moreover (and here it gets really theoretical
:-) it's possible to write polymorphic code that accepts either a
sequence or a number as argument, using only + and int* as operators.
In this case, type(a)() is even more attractive for getting the "zero"
of the group.

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


From guido@python.org  Fri Jun 13 13:42:20 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 08:42:20 -0400
Subject: [Python-Dev] Default constructor values (Re: [Python-checkins]
 python/dist/src/Doc/lib libfuncs.tex,1.134,1.135)
In-Reply-To: "Your message of Fri, 13 Jun 2003 10:34:49 +0200."
 <3EE98CA9.3020001@lemburg.com>
References: <200306120412.h5C4CQk03251@oma.cosc.canterbury.ac.nz>
 <200306130043.h5D0h9m30149@pcp02138704pcs.reston01.va.comcast.net>
 <3EE98002.2040205@lemburg.com> <200306131014.08761.aleaxit@yahoo.com>
 <3EE98CA9.3020001@lemburg.com>
Message-ID: <200306131242.h5DCgKX31159@pcp02138704pcs.reston01.va.comcast.net>

[MAL]
> No idea, why Guido couldn't have come up with a similar explanation
> or a simple "hey, at the time I thought it was better this
> way". That ignorace probably caused the heat on my side, not the
> subject itself.

Often my decisions are gut feelings and I have a hard time
rationalizing them.  *OF COURSE* I thought it was better this way
(else I wouldn't have done it), but I didn't think you'd take that as
an explanation -- we were already beyond that point and you demanded a
real explanation.

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



From jacobs@penguin.theopalgroup.com  Fri Jun 13 13:39:15 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Fri, 13 Jun 2003 08:39:15 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <r01050400-1026-525760AE9D9A11D7B4B1003065D5E7E4@[10.0.0.23]>
Message-ID: <Pine.LNX.4.44.0306130831420.19892-100000@penguin.theopalgroup.com>

On Fri, 13 Jun 2003, Just van Rossum wrote:
> The problem is that the pending calls mechanism is for the main thread
> onle, and involves globals (mainly ceval.c's 'pendingcalls' and
> 'things_to_do'). So the first thing we'd need to look into is moving
> those globals to the PyThreadState struct (or to PyThreadState's dict
> object).

Restricting SIGINT delivery is another reason why interrupts are only posted
to the main thread.  See python-dev March 2001 for a thread on that touches
on this issue.  I've been auditing the various thread implementations and
have patches for thread_solaris and thead_pth to bring them in line with how
thread_pthreads handles signal masking.  This will lift the second
requirement for limiting interrupts to the main thread for these platforms.

> (Btw. whatever we do, it won't interrupt blocking system calls, but I
> think that's fine. sys.interrupt() won't interrupt these either.)

It won't unless we add the ability to send a signal via pthread_kill (or the
equivalent) to request an interrupt.  Even then, killing a thread will still
be a fundamentally cooperative process.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From guido@python.org  Fri Jun 13 13:52:10 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 08:52:10 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: "Your message of Fri, 13 Jun 2003 06:27:27 EDT."
 <Pine.LNX.4.44.0306130616120.18906-100000@penguin.theopalgroup.com>
References: <Pine.LNX.4.44.0306130616120.18906-100000@penguin.theopalgroup.com>
Message-ID: <200306131252.h5DCqA831194@pcp02138704pcs.reston01.va.comcast.net>

[Kevin J]
> That chunk of code is very problematic.  Some platforms/threading libraries
> will deliver a SIGINT to all threads, which can abort many system calls that
> are not trivially restarted/restartable.

While I was worried about this when writing the original code (that's
the only way to explain some of the things it does), I'm not sure if
we really have to worry about such platforms any more; I certainly
have never heard a report of such behavior.  On Unix and Unixish
systems, pthreads rule.  Windows doesn't have real signals.  Mac OS is
now also Unix.  PalmOS doesn't have threads.  What other platforms are
relevant?

> To deliver a KeyboardInterrupt
> only to the main thread is problematic, since the other threads may
> misinterpret the failure as something else (EOF, fatal error, or worse,
> operation succeeded).

*If* the other threads indeed get their syscalls interrupted, this
would indeed be a problem.

> I understand the desire to smooth over platform differences in
> Python, but I'm not sure that this one (signal delivery policy to
> threads) is a good idea.  In fact, I'll try to find a real-world
> case where this kind of error occurs.

I'd appreciate it if you found one.  Nevertherless, I'm not sure if
the weakening of semantics would make sense.  Better to fix the
offending platform (possibly by using pthreads :-).

[Just]
> > Naming: putting this into main sounds just right, but I would
> > suggest to call it sys.interrupt() instead of
> > sys.interrupt_main(). That way *if* we ever add the possibility to
> > interrupt a non-main thread, sys.interrupt() could grow an
> > optional argument specifying the thread.
> 
> I Agree.

Hm...  I like it better in the thread module, and there
"thread.interrupt()" looks wrong, while "thread.interrupt_main()"
makes sense.

If and when the generalized functionality is implemented, I think the
use cases will be so different that a different name for it won't be a
big burden.  I call YAGNI on the naming consideration.

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



From jacobs@penguin.theopalgroup.com  Fri Jun 13 13:52:44 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Fri, 13 Jun 2003 08:52:44 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306131252.h5DCqA831194@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <Pine.LNX.4.44.0306130845390.19892-100000@penguin.theopalgroup.com>

On Fri, 13 Jun 2003, Guido van Rossum wrote:
> [Kevin J]
> > That chunk of code is very problematic.  Some platforms/threading libraries
> > will deliver a SIGINT to all threads, which can abort many system calls that
> > are not trivially restarted/restartable.
> 
> While I was worried about this when writing the original code (that's
> the only way to explain some of the things it does), I'm not sure if
> we really have to worry about such platforms any more; I certainly
> have never heard a report of such behavior.  On Unix and Unixish
> systems, pthreads rule.  Windows doesn't have real signals.  Mac OS is
> now also Unix.  PalmOS doesn't have threads.  What other platforms are
> relevant?

The thread_pthreads already masks signals to newly created threads.  I have
patches to add signal masking to solaris and pth threads.  I'm not sure how
much either are used anymore, though.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From guido@python.org  Fri Jun 13 14:11:47 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 09:11:47 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: "Your message of Fri, 13 Jun 2003 14:26:52 +0200."
 <r01050400-1026-525760AE9D9A11D7B4B1003065D5E7E4@[10.0.0.23]>
References: <r01050400-1026-525760AE9D9A11D7B4B1003065D5E7E4@[10.0.0.23]>
Message-ID: <200306131311.h5DDBlp31291@pcp02138704pcs.reston01.va.comcast.net>

> (Btw. whatever we do, it won't interrupt blocking system calls, but I
> think that's fine. sys.interrupt() won't interrupt these either.)

In particular, this means that a thread blocked waiting for a lock
won't be stopped until the lock is released by the thread that held
the lock.  If there's a deadlock, this may be never.  So the mechanism
won't help you to kill deadlocked threads.  (This can be alleviated by
using aquire() with a timeout everywhere; but the basic locks
currently don't have that feature, they only have a non-blocking
option.  And of course code using timeouts is more complicated to
write, and harder to read.)

There's also a race condition in the language design that would need
to be fixed before I'd like to have this feature.  As you know, the
proper idiom for using locks is:

  lock.acquire()
  try:
      ...critical section code...
  finally:
      lock.release()

It's important that the acquire() call is outside the try block,
because otherwise the release() call could be reached without the
acquire() call having returned.  But now if an asynchronous exception
arrives *after* acquire() returns but *before* the try block is
entered, the lock is never released!

I've seen a proposal (I think it was in a paper presented at the
second Little Languages conference at MIT, earlier this year) of a
syntactic extension that could be used:

  initially:
      lock.acquire()
  try:
      ...critical section code...
  finally:
      lock.release()

(this would block asynchronous signals during the initially: block)
but that's a pretty heavy-handed solution.

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


From guido@python.org  Fri Jun 13 14:18:14 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 09:18:14 -0400
Subject: [Python-Dev] porting problems
In-Reply-To: "Your message of Fri, 13 Jun 2003 12:51:04 BST."
 <MOELJIPGEEHBHCIFENHCCEFJCCAA.ajp@eutechnyx.com>
References: <MOELJIPGEEHBHCIFENHCCEFJCCAA.ajp@eutechnyx.com>
Message-ID: <200306131318.h5DDIEQ31329@pcp02138704pcs.reston01.va.comcast.net>

> Problem 1:
> I have compiled python2.2.3c1 for the xbox and the gamecube. When I import a
> large module (generated by swig) the xbox version takes 6MB whilst the
> gamecube takes 1MB. This is despite using the same custom malloc replacement
> code. This problem occurrs whenever the python module being imported gets
> bigger than a few thousand lines long. I do not know why the versions do not
> behave identically as they both are using a near identical hand generated
> pyconfig.h.

I believe the answer is not in Python, but in the details of the
architectures; *something* must be different, and I can't guess what.
I think you'll only find the answer by either (a) debugging the heck
out of it, or (b) asking on xbox and gamecube forums.

> Problem 2:
>   What d o I need to do to get errors on import etc to show up in my own
> custom error printing routines. t the moment I cannot find them unless I am
> using the very high python/c interface functions. (In this case I can set
> stderr to a custom class and everything works fine)

This is a Python question; it's probably best asked on c.l.py; I
recommend that you give a lot more detail about what you mean by
"custom error printing routines" -- without understanding that part I
can't even begin to understand the rest of your question.  (It's also
not clear what "errors on import etc" you are interested in catching
-- is this ImportError exceptions, or exceptions raised by the
imported module's code when it runs?  Is this about C extension
modules or Python modules?  And what do you mean when referring to
"very high python/c interface funtions"?  Etc.)  Please post those
details with your question on c.l.py.

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


From jacobs@penguin.theopalgroup.com  Fri Jun 13 14:20:33 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Fri, 13 Jun 2003 09:20:33 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306131311.h5DDBlp31291@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <Pine.LNX.4.44.0306130916100.19892-100000@penguin.theopalgroup.com>

On Fri, 13 Jun 2003, Guido van Rossum wrote:
> There's also a race condition in the language design that would need
> to be fixed before I'd like to have this feature.  As you know, the
> proper idiom for using locks is:
> 
>   lock.acquire()
>   try:
>       ...critical section code...
>   finally:
>       lock.release()

This just reminded me of a question that has been floating around in my
brain for a while.  Why doesn't Python support the following fully general
syntax for try-blocks:

  try:
    foo()
  except blah:
    ...
  except:
    ...
  else:
    ...
  finally:
    ...

I keep having to write:

  try:
    try:
      foo()
    except blah:
      ...
    except:
      ...
    else:
      ...
  finally:
    ...

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From bh@intevation.de  Fri Jun 13 14:29:23 2003
From: bh@intevation.de (Bernhard Herzog)
Date: 13 Jun 2003 15:29:23 +0200
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <Pine.LNX.4.44.0306130916100.19892-100000@penguin.theopalgroup.com>
References: <Pine.LNX.4.44.0306130916100.19892-100000@penguin.theopalgroup.com>
Message-ID: <6q8ys6f6mk.fsf@salmakis.intevation.de>

Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> Why doesn't Python support the following fully general
> syntax for try-blocks:
> 
>   try:
>     foo()
>   except blah:
>     ...
>   except:
>     ...
>   else:
>     ...
>   finally:
>     ...

Will an exception, return, continue or break in an except: or else:
block cause the finally: block to run?

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                           http://www.mapit.de/


From jacobs@penguin.theopalgroup.com  Fri Jun 13 14:33:31 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Fri, 13 Jun 2003 09:33:31 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <6q8ys6f6mk.fsf@salmakis.intevation.de>
Message-ID: <Pine.LNX.4.44.0306130932030.20473-100000@penguin.theopalgroup.com>

On 13 Jun 2003, Bernhard Herzog wrote:
> Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > Why doesn't Python support the following fully general
> > syntax for try-blocks:
> > 
> >   try:
> >     foo()
> >   except blah:
> >     ...
> >   except:
> >     ...
> >   else:
> >     ...
> >   finally:
> >     ...
> 
> Will an exception, return, continue or break in an except: or else:
> block cause the finally: block to run?

I'd say yes, since my use-case is one that is rewritten with a try: finally:
block enclosing the try: except: else: block.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From neal@metaslash.com  Fri Jun 13 14:50:22 2003
From: neal@metaslash.com (Neal Norwitz)
Date: Fri, 13 Jun 2003 09:50:22 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306131311.h5DDBlp31291@pcp02138704pcs.reston01.va.comcast.net>
References: <r01050400-1026-525760AE9D9A11D7B4B1003065D5E7E4@[10.0.0.23]>
 <200306131311.h5DDBlp31291@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20030613135022.GG30348@epoch.metaslash.com>

On Fri, Jun 13, 2003 at 09:11:47AM -0400, Guido van Rossum wrote:
> 
> There's also a race condition in the language design that would need
> to be fixed ...
> 
>   lock.acquire()
>   try:
>       ...critical section code...
>   finally:
>       lock.release()
> 
> I've seen a proposal (I think it was in a paper presented at the
> second Little Languages conference at MIT, earlier this year) of a
> syntactic extension that could be used:
> 
>   initially:
>       lock.acquire()
>   try:
>       ...critical section code...
>   finally:
>       lock.release()

Part of the idea (or at least my idea) behind adding the do/with
statement which was discussed a while ago was to fix this problem.

        with lock:
            ... critical section ...

would ensure that lock.release() is called properly.

Neal


From troels@2-10.org  Fri Jun 13 15:14:17 2003
From: troels@2-10.org (Troels Therkelsen)
Date: Fri, 13 Jun 2003 16:14:17 +0200
Subject: [Python-Dev] Confusing behaviour relating to module objects being GCed.
Message-ID: <DJECKOIDDEODMIODJIPHMEJICAAA.troels@2-10.org>

Hello Python-Dev,

First off, I apologise if it is inappropriate to post this question here --
feel free to tell me to buzz off ;-).  As far as introductions go, I'm just
one of the thousands of average Python users, and I am feeling a little
uncertain about posting to this mailinglist, but I really want to understand
what's going on.  I did post this message to c.l.py and nobody has seemed
to care to actually try to explain what is happening.

Anyway, I'm having a problem in a large framework relating to using custom
__import__ and reload hooks.  I've been able to reduce the code that
demonstrates this problem to this Python code:

Python 2.3b1 (#1, Apr 27 2003, 22:07:38)
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import new
>>> mone = new.module('mone')
>>> mone.mtwo = new.module('mtwo')
>>> mone.mtwo.var = 42
>>> exec "def func():\n  print var\n  delmtwo()\n  print var\n" in
mone.mtwo.__dict__
>>> def delmtwo():
...   delattr(mone, 'mtwo')
...
>>> mone.mtwo.delmtwo = delmtwo
>>> mone.mtwo.func()             # FIRST CASE
42
None
>>> mone.mtwo = new.module('mtwo')
>>> mone.mtwo.var = 42
>>> exec "def func():\n  print var\n  delmtwo()\n  print var\n" in
mone.mtwo.__dict__
>>> keepref = mone.mtwo
>>> mone.mtwo.delmtwo = delmtwo
>>> mone.mtwo.func()             # SECOND CASE
42
42

The problem is that after mone.mtwo.func() calls delmtwo() which removes the
mtwo module from mone and thus reduces the ref-count to 0 (in the first
case),
func.im_func.func_globals starts showing a very peculiar behaviour.
Basically,
all of the module-level variable *names* stay, but all the *values* become
None.  As the second call to func() demonstrates, if I keep a ref to the
module which is deleted from mone, everything is fine.

I am at a loss explaining this behaviour (not knowing anything about Python
internals) and I would greatly appreciate enlightment that either confirms
that this is a bug, or explains why it isn't :-)

Of course, if it is indeed a bug, I'll report it to Sourceforge... I just
don't
want to report it if it isn't.

Best regards,

Troels Therkelsen




From tobias.burnus@physik.fu-berlin.de  Fri Jun 13 15:30:45 2003
From: tobias.burnus@physik.fu-berlin.de (Tobias Burnus)
Date: Fri, 13 Jun 2003 16:30:45 +0200 (CEST)
Subject: [Python-Dev] Python language standard; LSB
Message-ID: <Pine.LNX.4.44.0306131627400.23790-100000@g31.physik.fu-berlin.de>

Hello,

one thing that prevents the linux standard base to include Python (or Perl
for that matter) is that there is no formal language standard with test
cases. (For the LSB a subset might be enough.)
http://www.linuxbase.org/futures/faq.html#scope

Exists there anywhere a rudimentary standard or are there plans to create
one?

Tobias



From skip@pobox.com  Fri Jun 13 15:44:39 2003
From: skip@pobox.com (Skip Montanaro)
Date: Fri, 13 Jun 2003 09:44:39 -0500
Subject: [Python-Dev] Python language standard; LSB
In-Reply-To: <Pine.LNX.4.44.0306131627400.23790-100000@g31.physik.fu-berlin.de>
References: <Pine.LNX.4.44.0306131627400.23790-100000@g31.physik.fu-berlin.de>
Message-ID: <16105.58199.889186.767447@montanaro.dyndns.org>

    Tobias> one thing that prevents the linux standard base to include
    Tobias> Python (or Perl for that matter) is that there is no formal
    Tobias> language standard with test cases. (For the LSB a subset might
    Tobias> be enough.)  http://www.linuxbase.org/futures/faq.html#scope

    Tobias> Exists there anywhere a rudimentary standard or are there plans
    Tobias> to create one?

None that I'm aware of.  Why is this important?  Many Linux vendors already
ship Python and Perl with their distributions.  In fact, several of them
rely heavily on one language or the other to develop their value-added
system administration tools.

Skip


From guido@python.org  Fri Jun 13 16:06:02 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 11:06:02 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: "Your message of Fri, 13 Jun 2003 09:20:33 EDT."
 <Pine.LNX.4.44.0306130916100.19892-100000@penguin.theopalgroup.com>
References: <Pine.LNX.4.44.0306130916100.19892-100000@penguin.theopalgroup.com>
Message-ID: <200306131506.h5DF62A31614@pcp02138704pcs.reston01.va.comcast.net>

> This just reminded me of a question that has been floating around in my
> brain for a while.  Why doesn't Python support the following fully general
> syntax for try-blocks:
> 
>   try:
>     foo()
>   except blah:
>     ...
>   except:
>     ...
>   else:
>     ...
>   finally:
>     ...
> 
> I keep having to write:
> 
>   try:
>     try:
>       foo()
>     except blah:
>       ...
>     except:
>       ...
>     else:
>       ...
>   finally:
>     ...

At some early point in Python's development, it did support this.  I
decided to take it out for two reasons: (1) There were so many cases
that I couldn't manage to create correct code; (2) the semantics
aren't clear: does an exception raised in any of the except clauses
jump to the finally clause or not?  I'd say it should, but it may not
be clear to users (because the except clauses don't apply to each
other).  It also complicates the bytecode generation: effectively, the
compiler has to generate the bytecode equivalent to the second form.
The second form makes this explicitly clear.

Anyway, I don't think I've seen many too many cases where this would
have saved an indentation level.

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


From guido@python.org  Fri Jun 13 16:08:25 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 11:08:25 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: "Your message of Fri, 13 Jun 2003 09:50:22 EDT."
 <20030613135022.GG30348@epoch.metaslash.com>
References: <r01050400-1026-525760AE9D9A11D7B4B1003065D5E7E4@[10.0.0.23]>
 <200306131311.h5DDBlp31291@pcp02138704pcs.reston01.va.comcast.net>
 <20030613135022.GG30348@epoch.metaslash.com>
Message-ID: <200306131508.h5DF8Pf31655@pcp02138704pcs.reston01.va.comcast.net>

> Part of the idea (or at least my idea) behind adding the do/with
> statement which was discussed a while ago was to fix this problem.
> 
>         with lock:
>             ... critical section ...
> 
> would ensure that lock.release() is called properly.

Right.  That was also my idea (I think many people've had this idea
:-).  It has the advantage of being more generally useful than adding
an initially clause to the try/finally statement.

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


From barry@python.org  Fri Jun 13 16:09:48 2003
From: barry@python.org (Barry Warsaw)
Date: 13 Jun 2003 11:09:48 -0400
Subject: [Python-Dev] Sporadic test failures in
 Lib/test/test_mimetools.py
In-Reply-To: <002a01c33179$d96fea20$125ffea9@oemcomputer>
References: <002a01c33179$d96fea20$125ffea9@oemcomputer>
Message-ID: <1055516988.8384.20.camel@barry>

On Fri, 2003-06-13 at 03:03, Raymond Hettinger wrote:
> This test fails about one every ten tries on my WinMe box
> and I won't be able to examine it for a few days:

Me neither, but I guess I don't believe the docstring for
mimetools.choose_boundary() very much <wink>.

-Barry




From guido@python.org  Fri Jun 13 16:15:33 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 11:15:33 -0400
Subject: [Python-Dev] Python language standard; LSB
In-Reply-To: "Your message of Fri, 13 Jun 2003 16:30:45 +0200."
 <Pine.LNX.4.44.0306131627400.23790-100000@g31.physik.fu-berlin.de>
References: <Pine.LNX.4.44.0306131627400.23790-100000@g31.physik.fu-berlin.de>
Message-ID: <200306131515.h5DFFX931704@pcp02138704pcs.reston01.va.comcast.net>

> one thing that prevents the linux standard base to include Python (or Perl
> for that matter) is that there is no formal language standard with test
> cases. (For the LSB a subset might be enough.)
> http://www.linuxbase.org/futures/faq.html#scope
> 
> Exists there anywhere a rudimentary standard or are there plans to create
> one?

Not really, and not that I'm aware of.  In practice, there's only one
Python implementation that could be used here (Jython doesn't make
sense in this context) so I'm not sure what a standardization effort
would buy us.  It's not like there are lots of diverging Python
distributions, like with Unix or the Linux kernel.  Standardizing on a
version might make sense; I would recommend using the 2.2 line of
releases, starting with 2.2.3 (the latest 2.2 release), until 2.3 is
considered stable.

There is of course a thorough standard test suite for Python
(contained in the test package in the standard library); Jython also
strives to pass this test suite (except for some parts of the test
suite that are platform specific).

Other than that, I expect that including Python in LSB is more a
matter of political will in the LSB committee than anything else.

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


From staschuk@telusplanet.net  Fri Jun 13 16:26:54 2003
From: staschuk@telusplanet.net (Steven Taschuk)
Date: Fri, 13 Jun 2003 09:26:54 -0600
Subject: [Python-Dev] Confusing behaviour relating to module objects being GCed.
In-Reply-To: <DJECKOIDDEODMIODJIPHMEJICAAA.troels@2-10.org>; from troels@2-10.org on Fri, Jun 13, 2003 at 04:14:17PM +0200
References: <DJECKOIDDEODMIODJIPHMEJICAAA.troels@2-10.org>
Message-ID: <20030613092654.A902@tibia.amotlpaa.bogus>

Quoth Troels Therkelsen:
> [...] I did post this message to c.l.py and nobody has seemed
> to care to actually try to explain what is happening.

I asked about the same thing in c.l.py on 23 May and got useful
replies:
    <http://groups.google.com/groups?th=e72d71f1ee1a0042>

The short explanation is that zapping the module's dict is useful
during interpreter shutdown, and it is assumed that modules do not
get collected except at shutdown.  The quick fix is thus simply
not to let your modules get collected.  (The normal import
mechanism does this by placing references in sys.modules.)

For more, see the aforelinked c.l.py thread.

-- 
Steven Taschuk                           staschuk@telusplanet.net
"I'm always serious, never more so than when I'm being flippant."
                            -- _Look to Windward_, Iain M. Banks


From guido@python.org  Fri Jun 13 16:30:51 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 11:30:51 -0400
Subject: [Python-Dev] Confusing behaviour relating to module objects being
 GCed.
In-Reply-To: "Your message of Fri, 13 Jun 2003 16:14:17 +0200."
 <DJECKOIDDEODMIODJIPHMEJICAAA.troels@2-10.org>
References: <DJECKOIDDEODMIODJIPHMEJICAAA.troels@2-10.org>
Message-ID: <200306131530.h5DFUph31786@pcp02138704pcs.reston01.va.comcast.net>

> Anyway, I'm having a problem in a large framework relating to using custom
> __import__ and reload hooks.  I've been able to reduce the code that
> demonstrates this problem to this Python code:
> 
> Python 2.3b1 (#1, Apr 27 2003, 22:07:38)
> [GCC 2.95.3 20010315 (release)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import new
> >>> mone = new.module('mone')
> >>> mone.mtwo = new.module('mtwo')
> >>> mone.mtwo.var = 42
> >>> exec "def func():\n  print var\n  delmtwo()\n  print var\n" in
> mone.mtwo.__dict__
> >>> def delmtwo():
> ...   delattr(mone, 'mtwo')
> ...
> >>> mone.mtwo.delmtwo = delmtwo
> >>> mone.mtwo.func()             # FIRST CASE
> 42
> None
> >>> mone.mtwo = new.module('mtwo')
> >>> mone.mtwo.var = 42
> >>> exec "def func():\n  print var\n  delmtwo()\n  print var\n" in
> mone.mtwo.__dict__
> >>> keepref = mone.mtwo
> >>> mone.mtwo.delmtwo = delmtwo
> >>> mone.mtwo.func()             # SECOND CASE
> 42
> 42
> 
> The problem is that after mone.mtwo.func() calls delmtwo() which
> removes the mtwo module from mone and thus reduces the ref-count to
> 0 (in the first case), func.im_func.func_globals starts showing a
> very peculiar behaviour.  Basically, all of the module-level
> variable *names* stay, but all the *values* become None.  As the
> second call to func() demonstrates, if I keep a ref to the module
> which is deleted from mone, everything is fine.
> 
> I am at a loss explaining this behaviour (not knowing anything about
> Python internals) and I would greatly appreciate enlightment that
> either confirms that this is a bug, or explains why it isn't :-)

The crucial part here is "not knowing anything about Python internals"
:-).  Please take some time to read the Python C source code.  If you
don't have it downloaded, you can view it online here:

  http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/

Look at the destructor for module objects (file
Objects/moduleobject.c, function module_dealloc()).  This is what
destroys the module when its refcount goes to zero.  It calls
_PyModule_Clear() which carefully sets all the module's global
variables to None.  The reason this is done is hard to explain; it has
to do with trying to break cyclical references between a module and
the classes and functions it defines, in an attempt at destroying as
many objects as possible when Python exits, in the hope that this will
cause user-defined destructors (__del__ methods) to be callled, which
might do useful things like flushing buffers, removing temporary
files, and releasing other external resources.  (Closing files and
releasing memory are *not* goals here, since this happens anyway when
a process exits.)

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


From pedronis@bluewin.ch  Fri Jun 13 16:25:37 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Fri, 13 Jun 2003 17:25:37 +0200
Subject: [Python-Dev] Caching of builtins and globals in action
In-Reply-To: <5.2.1.1.0.20030612134607.00a6c8b0@pop.bluewin.ch>
Message-ID: <5.2.1.1.0.20030613171951.024762a8@pop.bluewin.ch>

At 15:23 12.06.2003 +0200, Samuele Pedroni wrote:
>I have played a bit with the notion of caching builtin and global values 
>(to be precise the address of their dictionary entry) without changing 
>language semantics:
>
>I have an experimental modification to the interpreteter such that I get 
>these numbers: [bl_ is the baseline CVS code, ex_ is the modified interpreter]:

while obtaining a speedup when globals&built-ins are involved, as I said 
the modification preserve the current semantics, here are transcripts 
showing its working

Python 2.3b1+ (#100, Jun 12 2003, 22:25:31)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> def g():
...   y = 1
...   print y
...
 >>> g()
1
 >>> # g doesn't need a cache
...
 >>> def f():
...  print x
...  print x
...
 >>> x=2
 >>> f()
alloc cache
cache in code
caching
2
using cache
2
release my cache ref
 >>> # the cache is allocated on demand, stored away in code, and populated 
and used
...
 >>> f()
fast load cache
using cache
2
using cache
2
release my cache ref
 >>> # cache is retrieved from code and put to use
...
 >>> del x
 >>> x=3
 >>> f()
alloc cache
cache in code
caching
3
using cache
3
release my cache ref
 >>> # major change, cache discarded and rebuilt
...
 >>> def h():
...  print range
...
 >>> h()
alloc cache
cache in code
caching
<built-in function range>
release my cache ref
 >>> h()
fast load cache
using cache
<built-in function range>
release my cache ref
 >>> range = "range"
 >>> h()
alloc cache
cache in code
caching
range
release my cache ref
 >>> del range
 >>> h()
alloc cache
cache in code
caching
<built-in function range>
release my cache ref
 >>> # shadowing/unshadowing of built-ins work

Python 2.3b1+ (#102, Jun 12 2003, 22:35:51)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> c = compile("def f(): print x\nf()","<>","exec")
 >>> exec c in {'x': 1}
alloc cache
cache in code
caching
1
release my cache ref
 >>> exec c in {'x': 2}
alloc cache
cache in code
caching
2
release my cache ref



From walter@livinglogic.de  Fri Jun 13 16:37:51 2003
From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Fri, 13 Jun 2003 17:37:51 +0200
Subject: [Python-Dev] Sporadic test failures in	Lib/test/test_mimetools.py
In-Reply-To: <1055516988.8384.20.camel@barry>
References: <002a01c33179$d96fea20$125ffea9@oemcomputer> <1055516988.8384.20.camel@barry>
Message-ID: <3EE9EFCF.6000407@livinglogic.de>

Barry Warsaw wrote:

 > On Fri, 2003-06-13 at 03:03, Raymond Hettinger wrote:
 >
 >> This test fails about one every ten tries on my WinMe box
 >> and I won't be able to examine it for a few days:
 >
 > Me neither, but I guess I don't believe the docstring for
 > mimetools.choose_boundary() very much <wink>.

Maybe we should include an increasing counter in the output
from mimetools.choose_boundary()?

Bye,
    Walter Dörwald




From barry@python.org  Fri Jun 13 16:42:00 2003
From: barry@python.org (Barry Warsaw)
Date: 13 Jun 2003 11:42:00 -0400
Subject: [Python-Dev] Sporadic test failures
 in	Lib/test/test_mimetools.py
In-Reply-To: <3EE9EFCF.6000407@livinglogic.de>
References: <002a01c33179$d96fea20$125ffea9@oemcomputer>
 <1055516988.8384.20.camel@barry>  <3EE9EFCF.6000407@livinglogic.de>
Message-ID: <1055518920.8384.38.camel@barry>

On Fri, 2003-06-13 at 11:37, Walter D=F6rwald wrote:

> Maybe we should include an increasing counter in the output
> from mimetools.choose_boundary()?

Maybe we should finally deprecate mimetools? :)

-Barry




From tim.one@comcast.net  Fri Jun 13 17:46:22 2003
From: tim.one@comcast.net (Tim Peters)
Date: Fri, 13 Jun 2003 12:46:22 -0400
Subject: [Python-Dev] Sporadic test failures in	Lib/test/test_mimetools.py
In-Reply-To: <1055516988.8384.20.camel@barry>
Message-ID: <BIEJKCLHCIOIHAGOKOLHEEPCFOAA.tim.one@comcast.net>

choose_boundary() ends likes so:

    timestamp = '%.3f' % time.time()
    seed = `random.randint(0, 32767)`
    return _prefix + '.' + timestamp + '.' + seed

On Windows, time.time() updates fewer than 100 times per second (but more
than 10), so the timestamp format is overly optimistic about how much unique
info it can get out of time.time().  The test in question calls
choose_boundary() 100 times as fast as it can, and on Windows probably no
more than two distinct time.time() values are seen for the duration.  The
chance of a boundary string duplicate is then about the chance of seeing a
duplicate from the randint() in 100 tries, which is non-trivial.

So there are more-or-less obvious flaws in this algorithm, but I don't think
there exist any simple methods to generate a guid that's truly gu.  Using a
threadsafe counter instead of randomization would at least be unique across
a program run.



From guido@python.org  Fri Jun 13 18:01:26 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 13:01:26 -0400
Subject: [Python-Dev] Sporadic test failures in Lib/test/test_mimetools.py
In-Reply-To: "Your message of Fri, 13 Jun 2003 12:46:22 EDT."
 <BIEJKCLHCIOIHAGOKOLHEEPCFOAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHEEPCFOAA.tim.one@comcast.net>
Message-ID: <200306131701.h5DH1Q600372@pcp02138704pcs.reston01.va.comcast.net>

> choose_boundary() ends likes so:
> 
>     timestamp = '%.3f' % time.time()
>     seed = `random.randint(0, 32767)`
>     return _prefix + '.' + timestamp + '.' + seed
> 
> On Windows, time.time() updates fewer than 100 times per second (but more
> than 10), so the timestamp format is overly optimistic about how much unique
> info it can get out of time.time().  The test in question calls
> choose_boundary() 100 times as fast as it can, and on Windows probably no
> more than two distinct time.time() values are seen for the duration.  The
> chance of a boundary string duplicate is then about the chance of seeing a
> duplicate from the randint() in 100 tries, which is non-trivial.
> 
> So there are more-or-less obvious flaws in this algorithm, but I don't think
> there exist any simple methods to generate a guid that's truly gu.  Using a
> threadsafe counter instead of randomization would at least be unique across
> a program run.

A simple fix would be to change the seed to use 31 instead of 15 bits;
we now have a random generator capable of that.  Perhaps we should go
ahead and use even more bits...  Aren't we using mersenne Twister by
default?

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


From tim.one@comcast.net  Fri Jun 13 18:21:11 2003
From: tim.one@comcast.net (Tim Peters)
Date: Fri, 13 Jun 2003 13:21:11 -0400
Subject: [Python-Dev] Sporadic test failures in Lib/test/test_mimetools.py
In-Reply-To: <200306131701.h5DH1Q600372@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <BIEJKCLHCIOIHAGOKOLHCEPGFOAA.tim.one@comcast.net>

[guido@python.org]
> A simple fix would be to change the seed to use 31 instead of 15 bits;
> we now have a random generator capable of that.  Perhaps we should go
> ahead and use even more bits...  Aren't we using mersenne Twister by
> default?

In 2.3, right.  Not 2.2.  If we want a fix that's obviously collision-free
and can be backported too, a threadsafe counter seems simplest.



From guido@python.org  Fri Jun 13 18:40:40 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 13:40:40 -0400
Subject: [Python-Dev] VC 7.1 compiler for key developers - last call!
Message-ID: <200306131740.h5DHeeV00559@pcp02138704pcs.reston01.va.comcast.net>

The offer of a free VC 7.1 compiler from Microsoft for key Python
developers is still open.  We shouldn't switch to using the new
compiler now, but we should be prepared for having to switch at some
point in the future anyway (maybe for Python 2.4), and now is the time
to get the compiler.

The offer will get you the complete VC 7.1 Pro product from Microsoft
(which includes optimizer, debugger, docs, etc.).  It requires Windows
NT/2000/XP; it definitely doesn't run on Windows 05/98/Me.  (I've
tried!)  If you can't afford to upgrade to Windows NT/2000/XP, I have
an unused WinNT box that I can donate.

I suggest that all the key developers of core Python or key 3rd party
components (e.g. Numeric, wxPython) request a copy.  I need your
mailing address in order to give you your copy; if you already sent me
a message showing interest, please write again giving the full contact
info so I don't have to pull it off your website.

Last time I sent out this offer, I didn't get many responses.  If you
think some important 3rd party project developers aren't reading this
list, please forward this to them!

For 3rd party developers who don't get a free VC 7.1 kit, the MS
compilers themselves are freely downloadable (though the optimizer and
debugger aren't).  For pros and cons, please see the past discussion
on this topic.  Getting the free kit doesn't mean a commitment to
use it!

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


From guido@python.org  Fri Jun 13 18:48:48 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 13:48:48 -0400
Subject: [Python-Dev] Sporadic test failures in Lib/test/test_mimetools.py
In-Reply-To: "Your message of Fri, 13 Jun 2003 13:21:11 EDT."
 <BIEJKCLHCIOIHAGOKOLHCEPGFOAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHCEPGFOAA.tim.one@comcast.net>
Message-ID: <200306131748.h5DHmmV00727@pcp02138704pcs.reston01.va.comcast.net>

> > A simple fix would be to change the seed to use 31 instead of 15 bits;
> > we now have a random generator capable of that.  Perhaps we should go
> > ahead and use even more bits...  Aren't we using mersenne Twister by
> > default?
> 
> In 2.3, right.  Not 2.2.  If we want a fix that's obviously collision-free
> and can be backported too, a threadsafe counter seems simplest.

Sure, but that's more work.  Any volunteers?  If nobody volunteers,
I'll increase the counter range; it's better than nothing.

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


From tobias.burnus@physik.fu-berlin.de  Fri Jun 13 19:00:28 2003
From: tobias.burnus@physik.fu-berlin.de (Tobias Burnus)
Date: Fri, 13 Jun 2003 20:00:28 +0200 (CEST)
Subject: [Python-Dev] Python language standard; LSB
In-Reply-To: <200306131515.h5DFFX931704@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <Pine.LNX.4.44.0306131714060.25062-100000@g31.physik.fu-berlin.de>

Hi,

On Fri, 13 Jun 2003, Guido van Rossum wrote:
[Python Language Standard]
> Not really, and not that I'm aware of.  In practice, there's only one
> Python implementation that could be used here (Jython doesn't make
> sense in this context) so I'm not sure what a standardization effort
> would buy us.
Hmm, at least with PERL there are concerns that the different PERL version
have subtle differences. From the #lsb channel:
<chris> The problem we have here is the standardisation of perl
<chris> if we require perl on lsb systems, what does this really mean? Lots
        of versions out there with subtle incompatabilities

> It's not like there are lots of diverging Python distributions,
> like with Unix or the Linux kernel.
Well, even with things like the glibc, which exists only once and is in
principle the same, you might hit problems (e.g. with different forms of
threads) depending on the version.

> Standardizing on a version might make sense; I would recommend using the
> 2.2 line of releases, starting with 2.2.3 (the latest 2.2 release),
> until 2.3 is considered stable.
That was what chris ment (for Perl): While let's say Perl 5.6 and 5.8 are
similar, they are not identical for certain applications (especially
tainting and unicode). That is: One would like to know (e.g.) a subset
which is _guaranteed_ to work.

While Python is more stable than perl in this respect (at least I have
that expression) the problem is that there is no fixed python language:
With any new release not only bugs are fixed, but also new
language features are added. While this makes features-to-market faster,
it probably creates the problems that make it hard to "standardize"
python. This done when it is included in the LSB (kind of):
The programs have to behave _identical_ independend of the
python version.

> There is of course a thorough standard test suite for Python
Hmm. It should be somehow possible to get python (and perl) into the LSB,
hmm.

> Other than that, I expect that including Python in LSB is more a
> matter of political will in the LSB committee than anything else.
I'm not that sure, at least for LSB 2.0 which is supposed to be modulized
this might actually happen. (Though probably only if also Perl gets
included.)

Tobias



From guido@python.org  Fri Jun 13 19:36:05 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 14:36:05 -0400
Subject: [Python-Dev] Python language standard; LSB
In-Reply-To: "Your message of Fri, 13 Jun 2003 20:00:28 +0200."
 <Pine.LNX.4.44.0306131714060.25062-100000@g31.physik.fu-berlin.de>
References: <Pine.LNX.4.44.0306131714060.25062-100000@g31.physik.fu-berlin.de>
Message-ID: <200306131836.h5DIa5b01318@pcp02138704pcs.reston01.va.comcast.net>

> On Fri, 13 Jun 2003, Guido van Rossum wrote:
> [Python Language Standard]
> > Not really, and not that I'm aware of.  In practice, there's only one
> > Python implementation that could be used here (Jython doesn't make
> > sense in this context) so I'm not sure what a standardization effort
> > would buy us.
> Hmm, at least with PERL there are concerns that the different PERL version
> have subtle differences. From the #lsb channel:
> <chris> The problem we have here is the standardisation of perl
> <chris> if we require perl on lsb systems, what does this really mean? Lots
>         of versions out there with subtle incompatabilities
> 
> > It's not like there are lots of diverging Python distributions,
> > like with Unix or the Linux kernel.
> Well, even with things like the glibc, which exists only once and is in
> principle the same, you might hit problems (e.g. with different forms of
> threads) depending on the version.
> 
> > Standardizing on a version might make sense; I would recommend using the
> > 2.2 line of releases, starting with 2.2.3 (the latest 2.2 release),
> > until 2.3 is considered stable.
> That was what chris ment (for Perl): While let's say Perl 5.6 and 5.8 are
> similar, they are not identical for certain applications (especially
> tainting and unicode). That is: One would like to know (e.g.) a subset
> which is _guaranteed_ to work.
> 
> While Python is more stable than perl in this respect (at least I have
> that expression) the problem is that there is no fixed python language:
> With any new release not only bugs are fixed, but also new
> language features are added. While this makes features-to-market faster,
> it probably creates the problems that make it hard to "standardize"
> python. This done when it is included in the LSB (kind of):
> The programs have to behave _identical_ independend of the
> python version.

This reveals a hopelessly naive view on standardization.

> > There is of course a thorough standard test suite for Python
> Hmm. It should be somehow possible to get python (and perl) into the LSB,
> hmm.
> 
> > Other than that, I expect that including Python in LSB is more a
> > matter of political will in the LSB committee than anything else.
> I'm not that sure, at least for LSB 2.0 which is supposed to be modulized
> this might actually happen. (Though probably only if also Perl gets
> included.)

Why would Python only be included if Perl was also included?  As I
said, this is just politics.

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


From kbk@shore.net  Fri Jun 13 20:36:51 2003
From: kbk@shore.net (Kurt B. Kaiser)
Date: Fri, 13 Jun 2003 15:36:51 -0400
Subject: [Python-Dev] Where to put the interrupt module?
References: <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl>
 <200306122058.h5CKwd515011@odiug.zope.com>
 <m3n0gmzi6h.fsf@float.attbi.com>
 <200306131224.h5DCO7Q31067@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <m3y905ydkc.fsf@float.attbi.com>

Guido van Rossum <guido@python.org> writes:

>> > Hm, that's not bad.  It should be called sys.interrupt_main() then.
>> 
>> Works for me!
>> 
>> http://sourceforge.net/tracker/index.php?func=detail&aid=753733&group_id=5470&atid=305470
>
> Hm, but since this only makes sense if you have threads, shouldn't it
> be in the thread extension module?  Also, you forgot the patch to
> idlelib/run.py. :-)

Oh, I did that when I tested sys.interrupt_main()  :-)

But not checked in until I saw whether the patch would stick.

> If this makes sense to you, just check it in.

It sounds to me like thread.interrupt_main() is the way to go for now.

That naming makes the limitation evident.  If there should be a
subsequent generalization to the implementation, it's no problem to
update IDLE's run.py if thread.interrupt_main() gets deprecated.

I'll post a revision to the patch.

__
KBK


From skip@pobox.com  Fri Jun 13 20:47:43 2003
From: skip@pobox.com (Skip Montanaro)
Date: Fri, 13 Jun 2003 14:47:43 -0500
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <m3y905ydkc.fsf@float.attbi.com>
References: <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl>
 <200306122058.h5CKwd515011@odiug.zope.com>
 <m3n0gmzi6h.fsf@float.attbi.com>
 <200306131224.h5DCO7Q31067@pcp02138704pcs.reston01.va.comcast.net>
 <m3y905ydkc.fsf@float.attbi.com>
Message-ID: <16106.10847.236276.127901@montanaro.dyndns.org>

    Kurt> It sounds to me like thread.interrupt_main() is the way to go for
    Kurt> now.

How should dummy_thread be modified?  Something like

    def interrupt_main():
        raise KeyboardInterrupt

?

Skip


From cce@clarkevans.com  Fri Jun 13 21:30:04 2003
From: cce@clarkevans.com (Clark C. Evans)
Date: Fri, 13 Jun 2003 20:30:04 +0000
Subject: [Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky 'super' instances)
In-Reply-To: <000001c3316d$81d93d40$125ffea9@oemcomputer>
References: <16E1010E4581B049ABC51D4975CEDB88619A99@UKDCX001.uk.int.atosorigin.com> <5.1.1.6.0.20030612115854.0260e100@telecommunity.com> <20030612225645.GA20783@doublegemini.com> <000001c3316d$81d93d40$125ffea9@oemcomputer>
Message-ID: <20030613203004.GB23847@doublegemini.com>

On Fri, Jun 13, 2003 at 12:50:53AM -0400, Raymond Hettinger wrote:
| PEP 246 is a higher level protocol for seeking and applying
| pre-existing wrappers.

Right.

| >   The primary audience of PEP 246 are component/library developres
| >   who wish for their components to interoperate between frameworks.
| 
| This is why I don't think adapt() should be a builtin.  
| adapt.adapt() is not any harder to call than random.random()
| or glob.glob().

Make sense, although it would be nice if it was in the standard 
library so that people could start using it.   There really doesn't
seem to be any challengers; and without it in the standard library
it will be harder to facilitate adoption.   For example, Twisted 
relys upon code in Twisted in Python, and no other third party
modules save pyOpenSSL.   While PyProtocols may be out there, it
may be harder to encourage Twisted to include it as part of their
library without assigning copyright to Glyph.  (Or am I mistaken)

| Yep.  All it takes is one user to contribute code to support a protocol.
| My expectation is that the adapter code will (for the most part) be 
| contributed by a sophisticated component user rather than the original
| supplier of the component.  After all, if the supplier thought the
| foreign protocol was important, they would have supplied it in
| the first place.

Perhaps.  Although I think people in Twisted would include adapters
for Zope or Webware and vice versa.

| The nice thing about 246 is that the adapter code
| can be contributed without altering the original component code
| (OCP: open for extension, closed for modification).

Exactly.

| I don't see any significant downside to 246.  The code is simple
| enough.  It is useful in at least some cases and provides some
| support for interoperability.  I don't think it makes writing
| adapters any easier -- it does nothing to mitigate the problem
| of widely differing protocols with different underlying assumptions.
| Getting complete, bug free general purpose adoption will still
| remain a hard problem.  Cie le vie.

Yes.

| So, my questions is whether there is any reason not to adopt 246
| right away?  AFAICT, there is no competing proposal and nothing
| that would be harmed by adoption.  What's all the fuss about?

On Fri, Jun 13, 2003 at 08:19:59AM -0400, Phillip J. Eby wrote:
| Guido has said (and I agree) that if Python includes adapt(), then the
| Python standard library should use it.

When adapt() emerged, iterators were being formulated, and what
motivated me to write up the PEP is that I thought that the
function iter() provides (adapting an object to an iterator
protocol) needed to be more generic.   There are plenty of
places within Python where it could be applied.

| PyProtocols was my attempt to show that a PEP 246 mechanism can
| actually be pretty agnostic about what kind of interface objects 
| are used, just like the '+' operator is agnostic about what 
| object types it's used with.

Yes, but it also removes some requirements on an interface mechanism.

For instance, most of the interface strategies involve some sort
of list of interfaces, which could be changed easily without 
altering the inheritance hierarchy.   This is needed to be more
'dynamic' than what inheritance could tell you.

With adapt(), this requirement is less important, since someone
could always implement __conform__ or __adapt__ to get the dynamic
behavior they want.    The risk of these other, non-inheritance
mechanisms is that while they may be more dynamic, they may be
brittle (or ugly, IMHO).  

| Ah well.  :)  On the bright side, I think PyProtocols can alleviate
| *one* of his concerns, which was that having a Python-included interface
| type would make other interface types (e.g. Zope interfaces) "second-class
| citizens".  That is, I've demonstrated that it is possible to have a
| "protocol protocol", thus allowing different protocol or interface
| types to exist, even if they have no implementation in common (e.g. 
| Twisted, Zope, and PyProtocols).

Guido could start with a 'common demoninator' between what Twisted and
Zope do.  That is, he could define a protocol as a class/object which
uses inheritance, but not specify other mechanisms in which one
implements the interface, leaving this out in the open.

For example, he could create an interfaces.py which looks like...

   # inside interfaces.py
   class Iterable(object):
       def next():
           """ returns the next value in the iteration, or
               raises StopIteration to finish up
           """

Clearly someone could inherit from interfaces.Iterable to signal
that their object is iterable.  However, they could also use other
mechanism to signal that they are iterable, namely a __iter__ 
method...  and in this case,

    def iter(obj):
        return adapt(Iterable, obj)

Best,

Clark


From sismex01@hebmex.com  Fri Jun 13 21:17:13 2003
From: sismex01@hebmex.com (sismex01@hebmex.com)
Date: Fri, 13 Jun 2003 15:17:13 -0500
Subject: [Python-Dev] Python language standard; LSB
Message-ID: <F7DB8D13DB61D511B6FF00B0D0F06233051541DB@mail.hebmex.com>

> From: Guido van Rossum [mailto:guido@python.org] 
> Sent: Viernes, 13 de Junio de 2003 01:36 p.m.
> 
> > [...snippage...]
> >
> > While Python is more stable than perl in this respect (at 
> > least I have that expression) the problem is that there is
> > no fixed python language: With any new release not only bugs
> > are fixed, but also new language features are added. While
> > this makes features-to-market faster, it probably creates
> > the problems that make it hard to "standardize" python.
> > This done when it is included in the LSB (kind of):
> > The programs have to behave _identical_ independend of
> > the python version.
> 
> This reveals a hopelessly naive view on standardization.
> 

Actually, it's much, much worse than naive, it's fossilizing:
no program can continue evolving.  It reminds me of Microsoft's
DirectX thing, all recent versions contain all previous
versions, in order to replicate past version's behaviour,
downright to that caused by bugs or implementations errors.

> > > There is of course a thorough standard test suite for Python
> > Hmm. It should be somehow possible to get python (and perl) 
> > into the LSB, hmm.
> > 
> > > Other than that, I expect that including Python in LSB is more a 
> > > matter of political will in the LSB committee than anything else.
> > I'm not that sure, at least for LSB 2.0 which is supposed to be 
> > modulized this might actually happen. (Though probably only if also 
> > Perl gets
> > included.)
> 
> Why would Python only be included if Perl was also included?  
> As I said, this is just politics.
>

Tobias: What if certain [Python] program contains code that
depends on behaviour caused by a bug, or an "interim" feature?
Should Python become fossilized?

:-(

-gca

pd: Please excuse and ignore following legalese :-(
--
Advertencia:La informacion contenida en este mensaje es confidencial y
restringida, por lo tanto esta destinada unicamente para el uso de la
persona arriba indicada, se le notifica que esta prohibida la difusion de
este mensaje. Si ha recibido este mensaje por error, o si hay problemas en
la transmision, favor de comunicarse con el remitente. Gracias.


From guido@python.org  Fri Jun 13 21:32:03 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 13 Jun 2003 16:32:03 -0400
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: "Your message of Fri, 13 Jun 2003 14:47:43 CDT."
 <16106.10847.236276.127901@montanaro.dyndns.org>
References: <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl>
 <200306122058.h5CKwd515011@odiug.zope.com> <m3n0gmzi6h.fsf@float.attbi.com>
 <200306131224.h5DCO7Q31067@pcp02138704pcs.reston01.va.comcast.net>
 <m3y905ydkc.fsf@float.attbi.com>
 <16106.10847.236276.127901@montanaro.dyndns.org>
Message-ID: <200306132032.h5DKW3w05781@pcp02138704pcs.reston01.va.comcast.net>

> How should dummy_thread be modified?  Something like
> 
>     def interrupt_main():
>         raise KeyboardInterrupt

I don't think dummy_thread needs to support this API.

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


From cce@clarkevans.com  Fri Jun 13 22:44:11 2003
From: cce@clarkevans.com (Clark C. Evans)
Date: Fri, 13 Jun 2003 21:44:11 +0000
Subject: [Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky 'super' instances)
In-Reply-To: <20030613203004.GB23847@doublegemini.com>
References: <16E1010E4581B049ABC51D4975CEDB88619A99@UKDCX001.uk.int.atosorigin.com> <5.1.1.6.0.20030612115854.0260e100@telecommunity.com> <20030612225645.GA20783@doublegemini.com> <000001c3316d$81d93d40$125ffea9@oemcomputer> <20030613203004.GB23847@doublegemini.com>
Message-ID: <20030613214411.GA24220@doublegemini.com>

| On Fri, Jun 13, 2003 at 12:50:53AM -0400, Raymond Hettinger wrote:
| | I don't see any significant downside to 246.  The code is simple
| | enough.  It is useful in at least some cases and provides some
| | support for interoperability.
| ...
| | So, my questions is whether there is any reason not to adopt 246
| | right away?  AFAICT, there is no competing proposal and nothing
| | that would be harmed by adoption.  What's all the fuss about?
| 
| On Fri, Jun 13, 2003 at 08:19:59AM -0400, Phillip J. Eby wrote:
| | Guido has said (and I agree) that if Python includes adapt(), then the
| | Python standard library should use it.
| ...
| | PyProtocols was my attempt to show that a PEP 246 mechanism can
| | actually be pretty agnostic about what kind of interface objects 
| | are used, just like the '+' operator is agnostic about what 
| | object types it's used with.
| ...
| | Ah well.  :)  On the bright side, I think PyProtocols can alleviate
| | *one* of his concerns, which was that having a Python-included interface
| | type would make other interface types (e.g. Zope interfaces) "second-class
| | citizens".  That is, I've demonstrated that it is possible to have a
| | "protocol protocol", thus allowing different protocol or interface
| | types to exist, even if they have no implementation in common (e.g. 
| | Twisted, Zope, and PyProtocols).

Could this approach work:
  
   - use regular class inheritance for static requirements
   - use adapt() for dynamic or custom needs (as shown below)
   - let specific use cases further refine the requirements

This whole 'Interface' issue has been in the works for over
three years now, and potentially great interoperability 
between frameworks and components is being lost.   For example,
why not just have a 'interfaces.py' in the standard library.
The interface for iterators could be something like...
 
  # inside interfaces.py
  class Iterable(object):
      def next():
          """ returns the next value in the iteration, or
              raises StopIteration to finish up
           """
      def __conform__(cls, obj):
          try:
              return obj.__iter__()
          except AttributeError:
              pass

Then, iter() could be defined something like... 

  def iter(obj):
      return adapt(Iterable, obj)


Best,

Clark


From cce@clarkevans.com  Fri Jun 13 23:00:31 2003
From: cce@clarkevans.com (Clark C. Evans)
Date: Fri, 13 Jun 2003 22:00:31 +0000
Subject: [Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky 'super' instances)
Message-ID: <20030613220031.GA24393@doublegemini.com>

Oops.  Disregard the last post, it got away too soon.

| On Fri, Jun 13, 2003 at 12:50:53AM -0400, Raymond Hettinger wrote:
| | I don't see any significant downside to 246.  The code is simple
| | enough.  It is useful in at least some cases and provides some
| | support for interoperability.
| ...
| | So, my questions is whether there is any reason not to adopt 246
| | right away?  AFAICT, there is no competing proposal and nothing
| | that would be harmed by adoption.  What's all the fuss about?
| 
| On Fri, Jun 13, 2003 at 08:19:59AM -0400, Phillip J. Eby wrote:
| | Guido has said (and I agree) that if Python includes adapt(), then the
| | Python standard library should use it.
| ...
| | PyProtocols was my attempt to show that a PEP 246 mechanism can
| | actually be pretty agnostic about what kind of interface objects 
| | are used, just like the '+' operator is agnostic about what 
| | object types it's used with.
| ...
| | Ah well.  :)  On the bright side, I think PyProtocols can alleviate
| | *one* of his concerns, which was that having a Python-included interface
| | type would make other interface types (e.g. Zope interfaces) "second-class
| | citizens".  That is, I've demonstrated that it is possible to have a
| | "protocol protocol", thus allowing different protocol or interface
| | types to exist, even if they have no implementation in common (e.g. 
| | Twisted, Zope, and PyProtocols).

Could this approach work:
  
   - use regular class inheritance for static requirements
   - use adapt() for dynamic or custom needs (as shown below)
   - let specific use cases further refine the requirements

This whole 'Interface' issue has been in the works for over
three years now, and potentially great interoperability 
between frameworks and components is being lost.   For example,
why not just have a 'interfaces.py' in the standard library.
The interface for iterators could be something like...
 
  # inside interfaces.py
  class Iterable(object):
      def next():
          """ returns the next value in the iteration, or
              raises StopIteration to finish up
           """
      def __adapt__(cls, obj):
          try:
              return obj.__iter__()
          except AttributeError:
              pass
          // perhaps return a wrapper object
          // for other types, like lists...

     __adapt__ = classmethod(__adapt__)


Then, iter() could be defined something like... 

  def iter(obj):
      return adapt(Iterable, obj)


Best,

Clark


From pje@telecommunity.com  Fri Jun 13 22:35:19 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Fri, 13 Jun 2003 17:35:19 -0400
Subject: [Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky
 'super' instances)
In-Reply-To: <20030613214411.GA24220@doublegemini.com>
References: <20030613203004.GB23847@doublegemini.com>
 <16E1010E4581B049ABC51D4975CEDB88619A99@UKDCX001.uk.int.atosorigin.com>
 <5.1.1.6.0.20030612115854.0260e100@telecommunity.com>
 <20030612225645.GA20783@doublegemini.com>
 <000001c3316d$81d93d40$125ffea9@oemcomputer>
 <20030613203004.GB23847@doublegemini.com>
Message-ID: <5.1.1.6.0.20030613172136.02ead3d0@telecommunity.com>

At 09:44 PM 6/13/03 +0000, Clark C. Evans wrote:

>Could this approach work:
>
>    - use regular class inheritance for static requirements
>    - use adapt() for dynamic or custom needs (as shown below)
>    - let specific use cases further refine the requirements
>
>This whole 'Interface' issue has been in the works for over
>three years now, and potentially great interoperability
>between frameworks and components is being lost.   For example,
>why not just have a 'interfaces.py' in the standard library.
>The interface for iterators could be something like...

This is moot.  Guido has made it clear that until he's had time to think 
over all the issues, *no* interface implementation is getting in the 
standard library.

Meanwhile, PyProtocols is available under the PSF, so any framework that 
wants to bundle it in their distribution is free to do so.  If it becomes 
popular, I suppose there will need to be a versioning mechanism so a 
framework doesn't overwrite a newer version with an older one.  That's the 
only issue that would even be marginally resolved by inclusion in the 
standard library, apart from the implied "blessing".

However, I don't know that the "blessing" is even required at this 
point.  If PyProtocols (perhaps with the enhancements suggested by Samuele 
and others here) doesn't catch on, I'm not sure what else *could* make PEP 
246 popular.  Or to put it another way, if it doesn't catch on by its own 
merits, why decorate the standard library with interfaces to support it?

This is why one of my requirements for PyProtocols was that it absolutely 
had to support declaring adapters for built-in types, and why another one 
was that it should be possible for two people to independently declare 
equivalent or overlapping protocols, and then have a third party glue them 
together.  PEP 246 without an "open protocols" protocol, doesn't support 
this latter requirement.  That, I believe, is the heart of the "chicken and 
egg" problem for PEP 246 as a standalone protocol.  It's sort of like 
having 'iter()' but not having 'next()', or maybe the other way around.  :)



From drifty@alum.berkeley.edu  Fri Jun 13 23:49:54 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Fri, 13 Jun 2003 15:49:54 -0700
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306131311.h5DDBlp31291@pcp02138704pcs.reston01.va.comcast.net>
References: <r01050400-1026-525760AE9D9A11D7B4B1003065D5E7E4@[10.0.0.23]> <200306131311.h5DDBlp31291@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <3EEA5512.2070209@ocf.berkeley.edu>

Guido van Rossum wrote:
<SNIP>
> I've seen a proposal (I think it was in a paper presented at the
> second Little Languages conference at MIT, earlier this year) of a
> syntactic extension that could be used:
> 
>   initially:
>       lock.acquire()
>   try:
>       ...critical section code...
>   finally:
>       lock.release()
> 
> (this would block asynchronous signals during the initially: block)
> but that's a pretty heavy-handed solution.
> 

Yes, this was presented in a paper at the conference.

python-dev's-unofficial-librarian-and-historian-ly y'rs, Brett



From drifty@alum.berkeley.edu  Fri Jun 13 23:52:20 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Fri, 13 Jun 2003 15:52:20 -0700
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306132032.h5DKW3w05781@pcp02138704pcs.reston01.va.comcast.net>
References: <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl> <200306122058.h5CKwd515011@odiug.zope.com> <m3n0gmzi6h.fsf@float.attbi.com> <200306131224.h5DCO7Q31067@pcp02138704pcs.reston01.va.comcast.net> <m3y905ydkc.fsf@float.attbi.com> <16106.10847.236276.127901@montanaro.dyndns.org> <200306132032.h5DKW3w05781@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <3EEA55A4.6070005@ocf.berkeley.edu>

Guido van Rossum wrote:
>>How should dummy_thread be modified?  Something like
>>
>>    def interrupt_main():
>>        raise KeyboardInterrupt
> 
> 
> I don't think dummy_thread needs to support this API.
> 

It should at least have a function that does nothing to keep API 
compatibility.  So if Skip's suggestions is not liked just have ``def 
interrupt_main(): pass`` in the module.

-Brett




From niemeyer@conectiva.com  Sat Jun 14 00:24:17 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Fri, 13 Jun 2003 20:24:17 -0300
Subject: [Python-Dev] Python language standard; LSB
In-Reply-To: <16105.58199.889186.767447@montanaro.dyndns.org>
References: <Pine.LNX.4.44.0306131627400.23790-100000@g31.physik.fu-berlin.de> <16105.58199.889186.767447@montanaro.dyndns.org>
Message-ID: <20030613232416.GA28068@ibook.distro.conectiva>

> None that I'm aware of.  Why is this important?  Many Linux vendors already
> ship Python and Perl with their distributions.  In fact, several of them
> rely heavily on one language or the other to develop their value-added
> system administration tools.

... and infrastructure, installers, etc.

-- 
Gustavo Niemeyer
http://niemeyer.net


From niemeyer@conectiva.com  Sat Jun 14 00:43:59 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Fri, 13 Jun 2003 20:43:59 -0300
Subject: [Python-Dev] Python language standard; LSB
In-Reply-To: <Pine.LNX.4.44.0306131714060.25062-100000@g31.physik.fu-berlin.de>
References: <200306131515.h5DFFX931704@pcp02138704pcs.reston01.va.comcast.net> <Pine.LNX.4.44.0306131714060.25062-100000@g31.physik.fu-berlin.de>
Message-ID: <20030613234358.GB28068@ibook.distro.conectiva>

> That was what chris ment (for Perl): While let's say Perl 5.6 and 5.8 are
> similar, they are not identical for certain applications (especially
> tainting and unicode). That is: One would like to know (e.g.) a subset
> which is _guaranteed_ to work.
[...]

I think it's just a matter of including some specific Python version,
and using the documentation for that version. If you get Python 2.2.3,
any code designed for Python 2.2.3 will work on this Python version.
OTOH, you can't freeze Python development to make it compatible with
something forever. Not even programs like gcc work this way.

As I understand it, the LSB has come to solve compatibility problems
between different distributions of Linux. IMO, including Python in the
LSB won't buy us anything (besides some marketing ;-). As an example,
some time ago we could notice many users with problems about RedHat
including an obsolete Python. OTOH, this wasn't a Python fault. There
was a "standard" Python version which most distributions were following,
and RedHat was not following the "standard". This might happen with or
without LSB. Indeed, it has even more chance of happening if a *subset*
of Python is "included" in the LSB.

I must confess that nowadays I see the LSB mostly as a marketing tool,
being used as an argument against those that are afraid of being
attacked by the "Unix Syndrome" while adopting Linux.

> While Python is more stable than perl in this respect (at least I have
> that expression) the problem is that there is no fixed python language:
> With any new release not only bugs are fixed, but also new
> language features are added. While this makes features-to-market faster,

Please, have a look at the mailing list archive. You'll find *long*
discussions about this topic. :-)

> it probably creates the problems that make it hard to "standardize"
> python. This done when it is included in the LSB (kind of):
> The programs have to behave _identical_ independend of the
> python version.

I don't think standardization makes sense while we have a single
mainstream interpreter.

-- 
Gustavo Niemeyer
http://niemeyer.net


From drifty@alum.berkeley.edu  Sat Jun 14 00:58:15 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Fri, 13 Jun 2003 16:58:15 -0700
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306132032.h5DKW3w05781@pcp02138704pcs.reston01.va.comcast.net>
References: <BAAC10AD-9D15-11D7-9BA2-000A27B19B96@cwi.nl> <200306122058.h5CKwd515011@odiug.zope.com> <m3n0gmzi6h.fsf@float.attbi.com> <200306131224.h5DCO7Q31067@pcp02138704pcs.reston01.va.comcast.net> <m3y905ydkc.fsf@float.attbi.com> <16106.10847.236276.127901@montanaro.dyndns.org> <200306132032.h5DKW3w05781@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <3EEA6517.6010005@ocf.berkeley.edu>

Guido van Rossum wrote:
>>How should dummy_thread be modified?  Something like
>>
>>    def interrupt_main():
>>        raise KeyboardInterrupt
> 
> 
> I don't think dummy_thread needs to support this API.
> 

Well, it does now.  =)  I modified dummy_thread to raise 
KeyboardInterrupt after executing a function passed to start_new_thread 
if interrupt_main is called.  I think this simulates threading a little 
better since, calling this you have no clue how long it will take for 
your code to keep executing so might as well let whatever is running 
finish before the "main" thread gets its exception.

The only issue I see is someone calling interrupt_main and expecting an 
instant raise of KeyboardInterrupt if they are in the main thread. 
Damn, I need to modify the code again.

[A few minutes later...]

OK, done.  If someone thinks this is overblown then just back the 
changes out but I figure the module might as well *try* to simulate 
threads as best as it can without getting too complex.

-Brett



From pedronis@bluewin.ch  Sat Jun 14 02:15:46 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Sat, 14 Jun 2003 03:15:46 +0200
Subject: [Python-Dev] PEP280 and my experiment
Message-ID: <5.2.1.1.0.20030614025907.024b2458@pop.bluewin.ch>

some consideration on PEP 280: Optimizing access to globals

	http://www.python.org/peps/pep-0280.html


after my experiment.

1) in the PEP

"
Description


     (Note: Jason Orendorff writes: """I implemented this once, long
     ago, for Python 1.5-ish, I believe.  I got it to the point where
     it was only 15% slower than ordinary Python, then abandoned it.
     ;) In my implementation, "cells" were real first-class objects,
     and "celldict" was a copy-and-hack version of dictionary.  I
     forget how the rest worked."""  Reference:
     http://mail.python.org/pipermail/python-dev/2002-February/019876.html)
"

at least now you know there is hope :) for at a minimum some 15% _speedup_
when globals/builtins are heavely involved and a wash when they are not used.

2)

"
     When a function object is created from a code object and a celldict,
     the function object creates an array of cell pointers by asking the
     celldict for cells corresponding to the names in the code object's
     co_globals.  If the celldict doesn't already have a cell for a
     particular name, it creates and an empty one.  This array of cell
     pointers is stored on the function object as func_cells.  When a
     function object is created from a regular dict instead of a
     celldict, func_cells is a NULL pointer.
"

this is probably far from ideal for closures, OTOH with the right 
infrastructure it should be possible to store created caches e.g. in code 
objects and so reuse them.

regards.



From hitwc3d6c3@yahoo.com  Sat Jun 14 03:36:43 2003
From: hitwc3d6c3@yahoo.com (Willa Wang)
Date: Sat, 14 Jun 03 02:36:43 GMT
Subject: [Python-Dev] Protect yourself_ and your loved ones from Drunk Driving kzu
Message-ID: <k$02y-az-$2cq@dxwry>

This is a multi-part message in MIME format.

--.FB4.6.9DAD_D
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Mini-Keychain BREATHALYZER! A Must Have!

A Fast, Reusable, Pocket-sized Alcohol Detection Device for Use
Anywhere, Anytime Alcohol Consumption or Intoxication is a Concern.

Don't Be a Victim of Drunk Driving!

Makes a great personal item & gift. Almost everyone can use one, even if
your a casual drinker. It even has a flashlight built in for added
safety.

These retail for $99 in stores. Our exclusive internet-offer allows us
to sell the Mini-Breathalyzer for ONLY 39.95 !!!

***FREE*** Order Now and get a FREE Cable Descrambler ($70 Value)
FREE PayPerViews, Porno, Special Events & More...DONT MISS THIS AMAZING LI=
MITED TIME
DEAL!!

http://www.1ajdfhcy.com/cart/customer/product.php?productid=3D16153&partne=
r=3Daffil21&r=3D9876














=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
If you no longer wish to receive our offers and updates 
click below and we will promptly honor your request.
http://www.1ajdfhcy.com/1/





lncenwaxequ
--.FB4.6.9DAD_D--



From cnetzer@sonic.net  Sat Jun 14 05:09:03 2003
From: cnetzer@sonic.net (Chad Netzer)
Date: 13 Jun 2003 21:09:03 -0700
Subject: [Python-Dev] On the possibility of "optimizing" range() calls in for-loops
Message-ID: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>

I've been thinking about the possibility of an optimization of range()
calls in for-loops, replacing the list generation with a lazy range
object.

xrange(), in Python 2.3, now has an iterator, so it should be faster
than range() in for-loops, which is an incentive to use it more.
However, this does go against the overall desire to move away from
using xrange(), just as we have moved away from xreadlines(), etc.


So, I've been considering possible ways in which to 'optimize' the
following types of loops:


  for i in range( 1000 ):
      pass

or

  n = 1000
  for i in range( n ):
      pass


The main issue, as I see it, is substituting some form of lazy range
iterator, for the range() function, "behind the curtains" as it were.
People could gain the benefits of xrange() (less memory consumption,
probably faster looping), without having to promote the continued use
of xrange().

There would have to be logic to determine that the range function
being used is the builtin range, and not a shadowed version.  I assume
this can be done in a fairly straightforward manner at compile time.
I could use advice on whether this is feasible (but see below, first)

A further issue is the substitution itself.  As of 2.3b1 the range()
builtin is able to handle long integer objects larger than
sys.maxint.  xrange() is not so equipped, so it cannot be substituted
blindly for range() without examining the range() arguments.

However, as the second example above shows, the value of the arguments
would have to be determined at runtime.  In principle, a function
could be made which checked the arguments, and if they could be
handled by an xrange() object, it could be returned.  Otherwise, the
results of range() could be returned.  However, it is unclear whether
the results of this indirection (and double checking of the arguments)
would be a speed win (although the reduced memory requirements would
still exist).

Guido has already stated his opinion that xrange should NOT be
extended to handle values larger than sys.maxint (ie. he doesn't want
to give xrange() any more features).  A related option is to make a
kind of private lazy range-iterator object, would could be
unconditionally substituted for the range function, in for loops, as
compile time.  Based on my understanding of how the code generation
works, this could be made to work in principle.  However, without
introducing some new byte codes, it doesn't seem possible to have a
hidden, "private" iterator generator function.

So, without going into much further detail it seems there would be
only three feasible options.

1) Extend xrange() to handle long int arguments, to bring parity with
range(), and allowing unconditional substitution with range, in
for-loops.

2) Change byte code generation to allow substituting a private range
iterator (or range() iterator generator) that can handle all possible
ranges.

3) Forget it.  Not worth bothering about.

After thinking about it a lot, it seems number 3 has become the most
attractive (and likely) option. :)  Number 2 seems like a maintenance
nightmare, and number 1 would require the BDFL and community to change
the stance on extending the feature set of xrange().

I admit I haven't done extensive testing to determine whether this
optimization would really provide much benefit on the whole.
Certainly a grep through any large Python code base (say the standard
libraries) indicates that there are many uses of range() in for loops,
but typically for fairly small ranges, so the memory issue may not be
such a problem.  Also, should there ever be a Python 3, where range()
itself probably becomes lazy, the porting headaches, for this
particular issue, should be minimal compared to others.  (ie. xrange()
would become a synonym, of sorts, for the new range())

Anyway, I only bring it up because it is an issue that does get
discussed from time to time, usually with the idea that it "could"
possibly be done in the future.  I think if it should ever be done, it
should probably be done soon, just so that using xrange() will grow
less attractive, rather than more.  I'm interested to hear other
thoughts about this.


-- 
Chad Netzer <cnetzer (at) sonic (dot) net>



From aleaxit@yahoo.com  Sat Jun 14 10:10:20 2003
From: aleaxit@yahoo.com (Alex Martelli)
Date: Sat, 14 Jun 2003 11:10:20 +0200
Subject: [Python-Dev] On the possibility of "optimizing" range() calls in for-loops
In-Reply-To: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>
References: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>
Message-ID: <200306141110.20819.aleaxit@yahoo.com>

On Saturday 14 June 2003 06:09 am, Chad Netzer wrote:
> I've been thinking about the possibility of an optimization of range()
> calls in for-loops, replacing the list generation with a lazy range
> object.
>
> xrange(), in Python 2.3, now has an iterator, so it should be faster
> than range() in for-loops, which is an incentive to use it more.

Measuring is better than wondering:

with Python's current CVS:

[alex@lancelot Lib]$ python -O timeit.py 'for x in range(2000): pass'
1000 loops, best of 3: 257 usec per loop
[alex@lancelot Lib]$ python -O timeit.py 'for x in xrange(2000): pass'
1000 loops, best of 3: 220 usec per loop


with 2.2.2:

[alex@lancelot Lib]$ python2.2 -O timeit.py 'for x in range(2000): pass'
1000 loops, best of 3: 315 usec per loop
[alex@lancelot Lib]$ python2.2 -O timeit.py 'for x in xrange(2000): pass'
1000 loops, best of 3: 440 usec per loop

So, yes: xrange has accelerated SO much (by a factor of 2) as to
become measurably faster than range (by a little, about 15%) for
this specific usage, while it used to be substantially slower.

However, these days, if you're really in a hurry to repeat some action
2000 times (and don't need the iteration index, which is a reasonably
frequent case), there IS an alternative...:

alex@lancelot Lib]$ python -O timeit.py -s'import itertools' 'for x in 
itertools.repeat(None,2000): pass'
10000 loops, best of 3: 184 usec per loop
[alex@lancelot Lib]$ python -O timeit.py -s'import itertools' 'for x in 
itertools.repeat(None,2000): pass'
1000 loops, best of 3: 183 usec per loop

As you see, this is as much faster than xrange, as xrange is faster
than range.


Alex



From martin@v.loewis.de  Sat Jun 14 10:56:50 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 14 Jun 2003 11:56:50 +0200
Subject: [Python-Dev] On the possibility of "optimizing" range() calls in for-loops
In-Reply-To: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>
References: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>
Message-ID: <m3ptlhugm5.fsf@mira.informatik.hu-berlin.de>

Chad Netzer <cnetzer@sonic.net> writes:

> There would have to be logic to determine that the range function
> being used is the builtin range, and not a shadowed version.  I assume
> this can be done in a fairly straightforward manner at compile time.
> I could use advice on whether this is feasible (but see below, first)

It is not. Shadowing may occur well after the module import, by
inserting a name in the globals. If it were feasible, it would have
been done long ago.

Regards,
Martin



From pje@telecommunity.com  Sat Jun 14 13:46:29 2003
From: pje@telecommunity.com (Phillip J. Eby)
Date: Sat, 14 Jun 2003 08:46:29 -0400
Subject: [Python-Dev] PEP280 and my experiment
In-Reply-To: <5.2.1.1.0.20030614025907.024b2458@pop.bluewin.ch>
Message-ID: <5.1.0.14.0.20030614084405.01e44ec0@mail.telecommunity.com>

At 03:15 AM 6/14/03 +0200, Samuele Pedroni wrote:

>this is probably far from ideal for closures, OTOH with the right 
>infrastructure it should be possible to store created caches e.g. in code 
>objects and so reuse them.

Perhaps I'm misunderstanding, but wouldn't code objects be a bad place to 
put a cache, since the same code object can be used for more than one 
function object, each with different globals?  This would be problematic 
for code that uses 'exec code in dict' to load scripting code into a 
restricted execution space, for example.



From pedronis@bluewin.ch  Sat Jun 14 16:33:17 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Sat, 14 Jun 2003 17:33:17 +0200
Subject: [Python-Dev] PEP280 and my experiment
In-Reply-To: <5.1.0.14.0.20030614084405.01e44ec0@mail.telecommunity.com>
References: <5.2.1.1.0.20030614025907.024b2458@pop.bluewin.ch>
Message-ID: <5.2.1.1.0.20030614164444.02469450@pop.bluewin.ch>

At 08:46 14.06.2003 -0400, Phillip J. Eby wrote:
>At 03:15 AM 6/14/03 +0200, Samuele Pedroni wrote:
>
>>this is probably far from ideal for closures, OTOH with the right 
>>infrastructure it should be possible to store created caches e.g. in code 
>>objects and so reuse them.
>
>Perhaps I'm misunderstanding, but wouldn't code objects be a bad place to 
>put a cache, since the same code object can be used for more than one 
>function object, each with different globals?  This would be problematic 
>for code that uses 'exec code in dict' to load scripting code into a 
>restricted execution space, for example.

in that case the cache would be recreated each time, which is what was 
suggested to do anyway in the first place (maybe my previous mails were 
uncomprehensible) but my experimental code does already the right thing:

 >>> c = compile("def f(): print x\nf()","<>","exec")
 >>> exec c in {'x': 1}
alloc cache
cache in code
caching
1
release my cache ref
 >>> exec c in {'x': 2}
alloc cache
cache in code
caching
2
release my cache ref

This would happen if 'exec code in dict' is used to populate with a same 
set of definitions different namespaces. I think it's rare, another 
solution (less hackish) would be to associate with dicts used for globals a 
code -> cache mapping. This is maybe a bit more costly for the common case.

Anyway both the code -> cache mapping approach or the cache stored in code 
approach are better than recreating caches from scratch for closures. 
Storing caches in code is what my experiment does:

Python 2.3b1+ (#102, Jun 12 2003, 22:35:51)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> 0 # sets _
0
 >>> def r(f):
...   return lambda l: reduce(f,l)
...
 >>> import operator
 >>> r(operator.add)([3,2])
alloc cache
cache in code
caching
release my cache ref
5
 >>> r(operator.mul)([3,2])
fast load cache
using cache
release my cache ref
6
 >>> r(operator.sub)([3,2])
fast load cache
using cache
release my cache ref
1
 >>>

obviously storing caches also inside functions when they are created is 
even better but alone would not address the closure case.

regards. 



From cnetzer@sonic.net  Sat Jun 14 18:12:03 2003
From: cnetzer@sonic.net (Chad Netzer)
Date: 14 Jun 2003 10:12:03 -0700
Subject: [Python-Dev] On the possibility of "optimizing" range() calls
 in for-loops
In-Reply-To: <m3ptlhugm5.fsf@mira.informatik.hu-berlin.de>
References: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>
 <m3ptlhugm5.fsf@mira.informatik.hu-berlin.de>
Message-ID: <1055610723.1624.12.camel@adsl-209.204.179.133.sonic.net>

On Sat, 2003-06-14 at 02:56, Martin v. Löwis wrote:

> It is not. Shadowing may occur well after the module import, by
> inserting a name in the globals. If it were feasible, it would have
> been done long ago.

Somehow, when I dreamed all this up, I convinced myself that the
byte-compiler could know whether the range() in globals was the builtin,
and only do the optimization if it was.

Now, I can't even recall why I thought that. :)

Oh well.  Thanks.

Chad




From skip@mojam.com  Sun Jun 15 13:00:26 2003
From: skip@mojam.com (Skip Montanaro)
Date: Sun, 15 Jun 2003 07:00:26 -0500
Subject: [Python-Dev] Weekly Python Bug/Patch Summary
Message-ID: <200306151200.h5FC0Qc13280@manatee.mojam.com>

Bug/Patch Summary
-----------------

365 open / 3718 total bugs (-14)
159 open / 2211 total patches (+10)

New Bugs
--------

Enhancements to pdb.py when invoked as script (2003-06-08)
	http://python.org/sf/751124
Thread in threading.py can only be started once (2003-06-09)
	http://python.org/sf/751260
cPickle doesn't raise error, pickle does (recursiondepth) (2003-06-09)
	http://python.org/sf/751276
cPickle doesn't raise error, pickle does (UnpicklingError) (2003-06-09)
	http://python.org/sf/751279
smtplib crashes Windows Kernal. (2003-06-09)
	http://python.org/sf/751612
ftplib.retrbinary fails when called from retrlines callback (2003-06-09)
	http://python.org/sf/751758
2.2.3 Latex documentation missing from web page? (2003-06-10)
	http://python.org/sf/751933
graminit.[ch] don't build on windows (2003-06-10)
	http://python.org/sf/751956
Object destruction is broken for slots (2003-06-10)
	http://python.org/sf/751998
print in __getattr__ causes seg fault (2003-06-10)
	http://python.org/sf/752221
classmethod abuse --> SystemError (2003-06-12)
	http://python.org/sf/753451
Installing idle from new location (2003-06-12)
	http://python.org/sf/753518
websucker bug (2003-06-12)
	http://python.org/sf/753592
Infinite Loop in RE (2003-06-12)
	http://python.org/sf/753711
urlparse goes wrong with IP:port without scheme (2003-06-13)
	http://python.org/sf/754016
Exceptions when a thread exits (2003-06-14)
	http://python.org/sf/754449
sigwinch crashes python with curses (2003-06-14)
	http://python.org/sf/754455

New Patches
-----------

Let pprint.py use issubclass instead of is for type checking (2003-06-07)
	http://python.org/sf/750542
imghdr -- identify JPEGs in EXIF format (2003-06-08)
	http://python.org/sf/751031
Bug fix 750092: exec doesn't need newline (2003-06-08)
	http://python.org/sf/751038
Tutorial: remove string exceptions, add parnassus, #posts (2003-06-08)
	http://python.org/sf/751062
fix memory leaks in posixmodule on Windows (2003-06-08)
	http://python.org/sf/751114
Handle keyboard interrupts in SSL module (2003-06-10)
	http://python.org/sf/751916
cgitb: make more usable for 'binary-only' software (2003-06-10)
	http://python.org/sf/751943
ast-branch: multiple function fixes (2003-06-11)
	http://python.org/sf/752911
sys.interrupt_main() (2003-06-12)
	http://python.org/sf/753733
Enhanced webbrowser.py (2003-06-13)
	http://python.org/sf/754022
Enhance xrange description by mentioning itertools.repeat (2003-06-14)
	http://python.org/sf/754632

Closed Bugs
-----------

thread_pthread.h on FreeBSD (2002-05-08)
	http://python.org/sf/553736
re searches don't work with 4-byte unico (2002-08-23)
	http://python.org/sf/599377
SO name is too short!  Python 2.2.1 (2002-09-16)
	http://python.org/sf/610332
gethostbyname() blocks when threaded (2002-09-25)
	http://python.org/sf/614791
parameters for int(), str(), etc. (2002-12-30)
	http://python.org/sf/660022
./configure fails w/error: cannot compute sizeof (wchar_t), (2003-02-01)
	http://python.org/sf/678723
2 (more) bugs in turtle (2003-02-12)
	http://python.org/sf/685773
Move gmtime function from calendar to time module (2003-03-05)
	http://python.org/sf/697985
HTMLParser crash on glued tag attributes (2003-03-06)
	http://python.org/sf/699079
deepcopy can't copy self-referential new-style classes (2003-03-13)
	http://python.org/sf/702858
Problems printing and sleep (2003-03-15)
	http://python.org/sf/704194
pydoc support for keywords (2003-04-05)
	http://python.org/sf/715782
__slots__ broken in 2.3a with ("__dict__", ) (2003-04-18)
	http://python.org/sf/723540
overintelligent slice() behavior on integers (2003-04-18)
	http://python.org/sf/723806
Cannot retrieve name of super object (2003-04-28)
	http://python.org/sf/729103
test_tarfile writes in Lib/test directory (2003-05-02)
	http://python.org/sf/731403
Need an easy way to check the version (2003-05-06)
	http://python.org/sf/733231
pyxml setup error on Mac OS X (2003-05-08)
	http://python.org/sf/734844
os.symlink docstring is ambiguous. (2003-05-13)
	http://python.org/sf/737291
re.finditer() listed as new in 2.2.? (2003-05-19)
	http://python.org/sf/740026
test/build-failures on FreeBSD stable/current (2003-05-19)
	http://python.org/sf/740234
Can't browse methods and Classes (2003-05-20)
	http://python.org/sf/740407
sum() should be renamed (2003-05-26)
	http://python.org/sf/744051
anydbm and whichdb again (2003-05-27)
	http://python.org/sf/744687
xml.sax Contenthandler passes truncated data (2003-05-28)
	http://python.org/sf/745145
PACKAGE_*  in pyconfig.h (2003-05-30)
	http://python.org/sf/746012
TypeError raised when deepcopying built-in functions (2003-05-30)
	http://python.org/sf/746304
2.2.3c1 install-sh out of date (2003-05-30)
	http://python.org/sf/746366
bdist --formats=zip,wininst and bdist --formats=wininst,zip (2003-06-04)
	http://python.org/sf/749210
os.path.split does not handle . & .. properly (2003-06-04)
	http://python.org/sf/749261
strange  __subclasses__ behaviour (2003-06-05)
	http://python.org/sf/749480
copy raises SystemError when getstate raises exception (2003-06-05)
	http://python.org/sf/749831
--enable-shared fails on Solaris 9 with gcc-3.2.3 (2003-06-05)
	http://python.org/sf/749911

Closed Patches
--------------

Warn about inter-module assignments shadowing builtins (2003-03-28)
	http://python.org/sf/711448
time.tzset documentation (2003-05-08)
	http://python.org/sf/735051
Remove eval() from csv (2003-05-27)
	http://python.org/sf/744104


From Barbara" <uktfuocbp@compnews.co.uk  Sun Jun 15 12:59:59 2003
From: Barbara" <uktfuocbp@compnews.co.uk (Barbara)
Date: Sun, 15 Jun 2003 10:59:59 -0100
Subject: [Python-Dev] Like movies?
Message-ID: <995c01c33335$a52b56b0$a420c193@"Barbara" uktfuocbp>

This is a multi-part message in MIME format.

------=_NextPart_BF1_267D_1515B37C.BB9AA5C9
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


------=_NextPart_BF1_267D_1515B37C.BB9AA5C9
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D=22Content-Type=22 CONTENT=3D=22text/html;charset=3Di=
so-8859-1=22>
<=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22>
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D=22text/html; charset=3Diso-8=
859-1=22>
<META content=3D=22MSHTML 6.00.2600.0=22 name=3DGENERATOR>
<STYLE></STYLE>
</HEAD><FONT face=3DArial><FONT size=3D2>
<BODY>
<DIV>
<DIV>
<DIV><STRONG>If you have digital cable or get Pay-Per-View events, you'=
ve got 
to&nbsp;<A href=3D=22http://www.cover-pot.com/index.php?RepID=3DRS=22>c=
heck this 
out</A></STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D=23808080 size=3D1>If you don't want any more emails=
 from us, 
</FONT><A href=3D=22http://www.cover-pot.com/cleanlist.php=22><FONT col=
or=3D=23808080 
size=3D1>go here</FONT></A></DIV></DIV></DIV></BODY></HTML></FONT></FON=
T>


------=_NextPart_BF1_267D_1515B37C.BB9AA5C9--



From martin@v.loewis.de  Sun Jun 15 18:24:35 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 15 Jun 2003 19:24:35 +0200
Subject: [Python-Dev] Changes to IDLE
Message-ID: <m3wufn1cfg.fsf@mira.informatik.hu-berlin.de>

What is the current procedure for changing IDLE, for Python
committers?  Can I just commit changes to Lib/idlelib, do I need to
post them to idle-fork, or do I need to do something else?

[assuming, of course, that I think the change is sensible, and
I would consider applying it to be within my competence]

Regards,
Martin



From guido@python.org  Sun Jun 15 19:20:28 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 15 Jun 2003 14:20:28 -0400
Subject: [Python-Dev] Changes to IDLE
In-Reply-To: "Your message of 15 Jun 2003 19:24:35 +0200."
 <m3wufn1cfg.fsf@mira.informatik.hu-berlin.de>
References: <m3wufn1cfg.fsf@mira.informatik.hu-berlin.de>
Message-ID: <200306151820.h5FIKSB28491@pcp02138704pcs.reston01.va.comcast.net>

> What is the current procedure for changing IDLE, for Python
> committers?  Can I just commit changes to Lib/idlelib, do I need to
> post them to idle-fork, or do I need to do something else?
> 
> [assuming, of course, that I think the change is sensible, and
> I would consider applying it to be within my competence]

That's a good question; I'd like to see Kurt Kaiser's opinion on
that.  I doubt that it will be different than for any other part of
the Python library though: when in doubt, use a SF patch or email the
current maintainer.

Fixing clear and simple bugs without asking first would be fine,
presumably; when you get in the feature business, a discussion first
would be appropriate.  There's a TODO.txt file that lists things that
are presumably fair game (although again feature design should always
go through some discussion first).

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


From michel@dialnetwork.com  Sun Jun 15 20:29:42 2003
From: michel@dialnetwork.com (michel@dialnetwork.com)
Date: Sun, 15 Jun 2003 14:29:42 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
Message-ID: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>

Greetings,

After doing a whole heck of a lot of Java and Jython programming over the
last year I decided to work an idea of mine into a PEP after being
impressed with Java thread syncronization and frustrated with Python (it's
almost always the other way around...)

http://www.python.org/peps/pep-0319.html

Comments, please send to me. I think python-dev is the right forum for
discussion, otherwise someone will surely let me know and I'll go to
python-list.

Thanks!

-Michel



From michel@dialnetwork.com  Sun Jun 15 20:40:33 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Sun, 15 Jun 2003 14:40:33 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
Message-ID: <34254.66.19.48.90.1055706033.squirrel@squirrel.dialnetwork.com>

> Greetings,
>
> After doing a whole heck of a lot of Java and Jython programming over the
> last year I decided to work an idea of mine into a PEP after being
> impressed with Java thread syncronization and frustrated with Python (it's
> almost always the other way around...)
>
> http://www.python.org/peps/pep-0319.html

Oops I found an error.  In the 'asynchronize' keyword section the last
block of code should be:

        synchronize:
            while in_loop():
                change_shared_data()

                asynchronize:
                   do_blocking_io()

                change_shared_data2()

not:

        while in_loop():
            synchronize:
                change_shared_data()

                asynchronize:
                   do_blocking_io()

                change_shared_data2()

I've sent in a new revision.

-Michel


From kbk@shore.net  Sun Jun 15 20:34:54 2003
From: kbk@shore.net (Kurt B. Kaiser)
Date: Sun, 15 Jun 2003 15:34:54 -0400
Subject: [Python-Dev] Changes to IDLE
In-Reply-To: <200306151820.h5FIKSB28491@pcp02138704pcs.reston01.va.comcast.net> (Guido
 van Rossum's message of "Sun, 15 Jun 2003 14:20:28 -0400")
References: <m3wufn1cfg.fsf@mira.informatik.hu-berlin.de>
 <200306151820.h5FIKSB28491@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <m3llw3rv6p.fsf@float.attbi.com>

Guido van Rossum <guido@python.org> writes:
   [loewis]
>> What is the current procedure for changing IDLE, for Python
>> committers?  Can I just commit changes to Lib/idlelib, do I need to
>> post them to idle-fork, or do I need to do something else?
>> 
>> [assuming, of course, that I think the change is sensible, and
>> I would consider applying it to be within my competence]
>
> That's a good question; I'd like to see Kurt Kaiser's opinion on
> that.  I doubt that it will be different than for any other part of
> the Python library though: when in doubt, use a SF patch or email the
> current maintainer.

Exactly that.  IMHO we should emphasize stability, user-friendliness,
low surprise factor, and performance over features.  IDLE is the first
exposure to Python for many people, and it should be a good, solid
experience.

IMHO, as with Python, only the experts should be able to find (or even
stumble across) the expert features  :-)

This is not to say that IDLE should become static.  There is much
to do. 

Right now we're in beta mode, so, as with Python itself, we should
hold off on significant feature implementation and concentrate on
correctness and stability.

If you start on a bug, please assign it to yourself.  I've added
Martin to IDLEfork, anyone else, just ask.  But the bugs and patches
are hopefully going to zero there and anything new should be posted to
the Python trackers.

If you work on a feature, it's helpful to mention it somehow so we don't 
step on each other.  IDLE is big enough that people tend to concentrate
on certain areas: I was working on the RPC / subprocess / debuggers
and Stephen was working on the configuration system.

> Fixing clear and simple bugs without asking first would be fine,
> presumably; when you get in the feature business, a discussion first
> would be appropriate.  There's a TODO.txt file that lists things that
> are presumably fair game (although again feature design should always
> go through some discussion first).

Idle-dev continues to be the place for discussion.  (I do of course
follow Python-dev and Python-checkins.)

IDLEfork RIP.   I will release Version 1.0 when 2.3 comes out and then
go into bug fix mode to support the 2.2 userbase.
__
KBK


From martin@v.loewis.de  Sun Jun 15 21:50:14 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 15 Jun 2003 22:50:14 +0200
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
Message-ID: <m3isr712wp.fsf@mira.informatik.hu-berlin.de>

michel@dialnetwork.com writes:

> Comments, please send to me. I think python-dev is the right forum for
> discussion, otherwise someone will surely let me know and I'll go to
> python-list.

I find this underspecified. The section that says "Implementation"
really tries to explain what the *semantics* is of the proposed keywords,
yet it fails to spell out many interesting details.

For example, the PEP nowhere says what the semantics of the
"synchronize" keyword is. Apparently, execution may stop when entering
the synchronize block under certain circumstances. But under what
circumstances?

One may interpret that the example without synchronize is meant to do
the same thing as the code with synchronize, but this does not help
much, since I don't know what the "acquire_lock" and "release_lock"
global functions are.

Also, when talking about targets, I notice that these are
expressions. I assume that synchronization only happens when the
"same" object is used twice. What kind of "sameness" does that assume?
Are there really no restrictions? e.g. would

  def foo():
    synchronize "a"+"b":
      print 1

  def bar():
    synchronize "a"+"b":
      print 2

be valid? What would be the meaning of this code?

Regards,
Martin


From gward@python.net  Sun Jun 15 22:26:55 2003
From: gward@python.net (Greg Ward)
Date: Sun, 15 Jun 2003 17:26:55 -0400
Subject: [Python-Dev] zipfile.py (SF #755031)
Message-ID: <20030615212655.GA3575@cthulhu.gerg.ca>

Hi Jim -- are you still the prime suspect for zipfile.py?  If so, could
you take a look at http://python.org/sf/755031 and let me know if I'm
onto something, or if zipfile.py is really in the right here?

Thanks --

        Greg
-- 
Greg Ward <gward@python.net>                         http://www.gerg.ca/
Sure, I'm paranoid... but am I paranoid ENOUGH?


From andrew@acooke.org  Sun Jun 15 22:54:37 2003
From: andrew@acooke.org (andrew cooke)
Date: 15 Jun 2003 17:54:37 -0400
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
Message-ID: <87fzmbdn1e.fsf@acooke.org>

there is also discussion at the moment of thread-synchronisation on
the stackless python list.  people were considering ideas related to
futures and csp (influenced largely by the oz language, i think).

maybe stackless, with its stronger emphasis on threads, is the place
to iron out a really good solution to multi-threading before making
changes to standard python?

personal opinion: while java may be better than python in this respect
i think there are much better solutions out there.  i'm a java
programmer and in my last project, which was multi-threaded, most bugs
came from threading issues.  there seems to be a lot of research and
new ideas in this area and it would be a pity if python only matched
java, when there may be the possibility to surpass it...

andrew

michel@dialnetwork.com writes:
> Greetings,
> 
> After doing a whole heck of a lot of Java and Jython programming over the
> last year I decided to work an idea of mine into a PEP after being
> impressed with Java thread syncronization and frustrated with Python (it's
> almost always the other way around...)
> 
> http://www.python.org/peps/pep-0319.html
> 
> Comments, please send to me. I think python-dev is the right forum for
> discussion, otherwise someone will surely let me know and I'll go to
> python-list.
> 
> Thanks!
> 
> -Michel
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> 

-- 
http://www.acooke.org



From jeffh@ActiveState.com  Mon Jun 16 00:29:11 2003
From: jeffh@ActiveState.com (Jeff Hobbs)
Date: Sun, 15 Jun 2003 16:29:11 -0700
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <3EE8FC58.3010106@v.loewis.de>
Message-ID: <PDEDIFMNJCFOKJPHIFJNIEFNDNAA.jeffh@activestate.com>

My ears were ringing for this one, so I thought I'd add some comments.

Martin v. Lowis wrote:
> >>Ask Redhat why they chose to hack Tcl to better accomodate Python.
> >
> > I take it 'better' is ironically here? :)
>
> Well, they decided to built Python 2.2 in UCS-4 mode, which is,
> in general, a good thing, except that it doesn't work. In particular,
> sre and _tkinter don't work well; _tkinter does not work at all.
> Instead of fixing _tkinter (which I now did for Python 2.3), they
> chose to hack Tcl instead, to extend it to UCS-4 mode.

Can someone explain to me why moving to UCS-4 is a good thing?  What
RedHat did is a Bad Thing, in completely screwing with compatability
(with no warning).  See below.

> Now I have to deal with standard Tcl, which is UCS-2, and can support
> both UCS-2 and UCS-4 Python _tkinter with that (2.2 would mandate
> UCS-2 Python for _tkinter). I also have to support Redhat Tcl, which
> is UCS-4. I chose to only support this in combination with UCS-4
> Python. If anybody wants the combination Redhat Tcl + UCS-2 Python,
> feel free to develop a patch.
>
> > Redhat does have bugfix updates, I will look if they know something
> > about this tomorrow (IIRC they have a buglist).
>
> It's not a bug. They *really* made this change to support their own
> build of Python. Unfortunately, they have thereby tied Python to UCS-4
> on Redhat 9. Their change is a hack, though, as Tcl does not really
> support UCS-4 - it merely compiles now, but don't dare to use non-BMP
> characters.

What UCS-4 support are you looking for that doesn't seem to exist?
While Tcl is agnostic about non-BMP chars (all 2 of them ... ha ha),
it does have correct UCS-4 support (not completely though with how
RedHat patched it).  This has been discussed before briefly here:

https://sourceforge.net/tracker/?func=detail&aid=578030&group_id=10894&atid=
110894

A Tcl_UniChar is 32-bits and TCL_UTF_MAX is 6 (normally it is 3),
which represents the number of utf-8 bytes that are valid in sequence.
Strings going through Tcl are handled as either utf-8 char*s or utf-32
(aka UCS-4) Tcl_UniChar*s.

I do realize that correct handling on non-BMP characters requires
some more work, but that is orthogonal to this issue.  While UCS-4
opens up more code points to allow non-BMP chars, there are very few
in that range at this point.  The bigger issue is that in changing
the basic Tcl_UniChar size, you break the binary compatability rules.
RH9 is the only version/distro to use 32-bit Tcl_UniChar, which
breaks compatability with extensions build on other versions/distros.

This is particularly bad for Tcl, which has the stubs mechanism that
allows for (promises really) upwards binary compatability for an
extension build against 8.x with 8.y where y >= x.  RH breaks that,
and that is surprising users.

Also, while Tcl can build and works just find with 32-bit Tcl_UniChar,
but I don't recall testing Tk when I tested Tcl.  Checking on a
rebuild now, it does appear that Tk operates just fine.  However, it
does consume a lot more memory.

I finally found the source RPMs for Tcl that RH9 uses and checked
out there patch.  It's not even correct.  You have to modify
tcl/generic/regcustom.h as well to account for Tcl_UniChar being
32-bits.  IOW, it's very annoying to me that someone at RedHat went
blundering around in the dark making these modifications when it is
fairly easy to find and communicate with the core developers on the
what, how and why of doing things correctly.

So I understand the need to deal with varying UCS-2 and UCS-4 Tcl
builds, but I can't imagine needing UCS-4 Tcl with UCS-2 Python
because I don't think anyone is crazy enough to do that combo.

BTW, cc me on any follow-up, as I am not on the list.

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/
      Tcl Support and Productivity Solutions



From greg@cosc.canterbury.ac.nz  Mon Jun 16 02:17:06 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 16 Jun 2003 13:17:06 +1200 (NZST)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <Pine.LNX.4.44.0306130616120.18906-100000@penguin.theopalgroup.com>
Message-ID: <200306160117.h5G1H6410465@oma.cosc.canterbury.ac.nz>

Kevin Jacobs <jacobs@penguin.theopalgroup.com>:

> That chunk of code is very problematic.  Some platforms/threading libraries
> will deliver a SIGINT to all threads, which can abort many system calls that
> are not trivially restarted/restartable.

But aren't we just talking about having one thread explicitly cause an
asynchronous exception to be raised in another? That's a different
thing from handling Unix signals.

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



From jacobs@penguin.theopalgroup.com  Mon Jun 16 02:23:09 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Sun, 15 Jun 2003 21:23:09 -0400 (EDT)
Subject: [Python-Dev] Where to put the interrupt module?
In-Reply-To: <200306160117.h5G1H6410465@oma.cosc.canterbury.ac.nz>
Message-ID: <Pine.LNX.4.44.0306152120380.15823-100000@penguin.theopalgroup.com>

On Mon, 16 Jun 2003, Greg Ewing wrote:
> Kevin Jacobs <jacobs@penguin.theopalgroup.com>:
> > That chunk of code is very problematic.  Some platforms/threading libraries
> > will deliver a SIGINT to all threads, which can abort many system calls that
> > are not trivially restarted/restartable.
> 
> But aren't we just talking about having one thread explicitly cause an
> asynchronous exception to be raised in another? That's a different
> thing from handling Unix signals.

Yes, but the implementation of these two things are somewhat intertwined. 
I'm not saying that it will be hard to sort out; just that those working on
it should be aware of some of the potential pitfalls.  If due care isn't
taken, then the behavior of SIGINT delivery could change for all Unix-like
non-pthread platforms.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From guido@python.org  Mon Jun 16 02:30:12 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 15 Jun 2003 21:30:12 -0400
Subject: [Python-Dev] New PEP: 319
In-Reply-To: "Your message of 15 Jun 2003 17:54:37 EDT."
 <87fzmbdn1e.fsf@acooke.org>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
 <87fzmbdn1e.fsf@acooke.org>
Message-ID: <200306160130.h5G1UCD29487@pcp02138704pcs.reston01.va.comcast.net>

> there is also discussion at the moment of thread-synchronisation on
> the stackless python list.  people were considering ideas related to
> futures and csp (influenced largely by the oz language, i think).

If someone could summarize those ideas here, that would be great (I
have no time to read the oz reference manual, alas).

> maybe stackless, with its stronger emphasis on threads, is the place
> to iron out a really good solution to multi-threading before making
> changes to standard python?

Um, Stackless has a very different notion of threads than core
Python.  Stackless threads are non-pre-emptive and cannot be used for
overlapping I/O, I believe (at least not easily).

> personal opinion: while java may be better than python in this respect
> i think there are much better solutions out there.  i'm a java
> programmer and in my last project, which was multi-threaded, most bugs
> came from threading issues.

In any project that is multi-threaded, most bugs will come from
threading issues.  This is regardless of programming language -- it's
a deep, as yet ununderstood property of threads.

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


From aahz@pythoncraft.com  Mon Jun 16 02:40:19 2003
From: aahz@pythoncraft.com (Aahz)
Date: Sun, 15 Jun 2003 21:40:19 -0400
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
Message-ID: <20030616014019.GA22785@panix.com>

On Sun, Jun 15, 2003, michel@dialnetwork.com wrote:
> 
> After doing a whole heck of a lot of Java and Jython programming over
> the last year I decided to work an idea of mine into a PEP after being
> impressed with Java thread syncronization and frustrated with Python
> (it's almost always the other way around...)
>
> http://www.python.org/peps/pep-0319.html

You need to be *much* clearer about the proposed interface between the
``synchronize`` keyword and Python objects.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From kbk@shore.net  Mon Jun 16 02:55:25 2003
From: kbk@shore.net (Kurt B. Kaiser)
Date: Sun, 15 Jun 2003 21:55:25 -0400
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <200306160130.h5G1UCD29487@pcp02138704pcs.reston01.va.comcast.net> (Guido
 van Rossum's message of "Sun, 15 Jun 2003 21:30:12 -0400")
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
 <87fzmbdn1e.fsf@acooke.org>
 <200306160130.h5G1UCD29487@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <m3wufmrdki.fsf@float.attbi.com>

Guido van Rossum <guido@python.org> writes:

> In any project that is multi-threaded, most bugs will come from
> threading issues.  This is regardless of programming language -- it's
> a deep, as yet ununderstood property of threads.

I'll second that.  They require a different and paranoid viewpoint :-\
They're hard to debug and it's difficult to assure good coverage when
testing.  I've also seen new problems arise when switching to a faster
processor.
__
KBK


From guido@python.org  Mon Jun 16 02:58:01 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 15 Jun 2003 21:58:01 -0400
Subject: [Python-Dev] New PEP: 319
In-Reply-To: "Your message of Sun, 15 Jun 2003 21:40:19 EDT."
 <20030616014019.GA22785@panix.com>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
 <20030616014019.GA22785@panix.com>
Message-ID: <200306160158.h5G1w1a29648@pcp02138704pcs.reston01.va.comcast.net>

> On Sun, Jun 15, 2003, michel@dialnetwork.com wrote:
> > 
> > After doing a whole heck of a lot of Java and Jython programming over
> > the last year I decided to work an idea of mine into a PEP after being
> > impressed with Java thread syncronization and frustrated with Python
> > (it's almost always the other way around...)
> >
> > http://www.python.org/peps/pep-0319.html

[Aahz]
> You need to be *much* clearer about the proposed interface between the
> ``synchronize`` keyword and Python objects.

I agree with Aahz; especially the scope of the lock used by an
anonymous synchronize block is ambiguous in the current PEP.  In one
example it appears that there is a lock associated with each
unqualified use of the synchronize keyword; in another, it seems that
unqualified uses in the same class share a lock.

Please try to explain the semantics of named and unnamed synchronize
calls entirely in terms of code that would work in current Python,
without using English (other than "this code is equivalent to that
code").

I'd also like to see how 'asynchronize' works with condition
variables, which seem to be the most common use for temporarily
unlocking.  (Your example of how code would do this without
asynchronize has a bug, by the way; if the I/O operation raises an
exception, the finally clause will attempt to release an already
released lock.)

I think the PEP would be clearer if it was considerably shorter and to
the point, with fewer examples and a more exact specification.

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


From python@rcn.com  Mon Jun 16 04:59:33 2003
From: python@rcn.com (Raymond Hettinger)
Date: Sun, 15 Jun 2003 23:59:33 -0400
Subject: [Python-Dev] On the possibility of "optimizing" range() calls in for-loops
References: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>
Message-ID: <00d401c333bb$b2519da0$125ffea9@oemcomputer>

[Chad Netzer]
> The main issue, as I see it, is substituting some form of lazy range
> iterator, for the range() function, "behind the curtains" as it were.
> People could gain the benefits of xrange() (less memory consumption,
> probably faster looping), without having to promote the continued use
> of xrange().

The SF patch manager has a workable implementation of your idea:

    www.python.org/sf/738094  for i in range(N) optimization 


The jury is still out on whether it is an elegant, brilliant patch or
a horrendous hack.


Raymond Hettinger



From aahz@pythoncraft.com  Mon Jun 16 05:08:53 2003
From: aahz@pythoncraft.com (Aahz)
Date: Mon, 16 Jun 2003 00:08:53 -0400
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <200306160158.h5G1w1a29648@pcp02138704pcs.reston01.va.comcast.net>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com> <20030616014019.GA22785@panix.com> <200306160158.h5G1w1a29648@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20030616040853.GA2499@panix.com>

On Sun, Jun 15, 2003, Guido van Rossum wrote:
> [Aahz]
>> On Sun, Jun 15, 2003, michel@dialnetwork.com wrote:
>>> 
>>> After doing a whole heck of a lot of Java and Jython programming over
>>> the last year I decided to work an idea of mine into a PEP after being
>>> impressed with Java thread syncronization and frustrated with Python
>>> (it's almost always the other way around...)
>>>
>>> http://www.python.org/peps/pep-0319.html
>> 
>> You need to be *much* clearer about the proposed interface between the
>> ``synchronize`` keyword and Python objects.
> 
> I agree with Aahz; especially the scope of the lock used by an
> anonymous synchronize block is ambiguous in the current PEP.  In one
> example it appears that there is a lock associated with each
> unqualified use of the synchronize keyword; in another, it seems that
> unqualified uses in the same class share a lock.
> 
> Please try to explain the semantics of named and unnamed synchronize
> calls entirely in terms of code that would work in current Python,
> without using English (other than "this code is equivalent to that
> code").

It occurs to me that my comment was actually insufficiently clear: what
I mean by "interface" is, "What methods get called on which Python
objects?"  In particular, read closely the documentation on such things
as iterators (and the way they work with ``for`` loops) and the
sequence/mapping protocol.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From michel@dialnetwork.com  Mon Jun 16 07:24:49 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Mon, 16 Jun 2003 01:24:49 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <200306160158.h5G1w1a29648@pcp02138704pcs.reston01.va.comcast.net>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com><20030
 616014019.GA22785@panix.com>
 <200306160158.h5G1w1a29648@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <34511.66.19.39.176.1055744689.squirrel@squirrel.dialnetwork.com>

>> You need to be *much* clearer about the proposed interface between the
>> ``synchronize`` keyword and Python objects.
>
> I agree with Aahz; especially the scope of the lock used by an
> anonymous synchronize block is ambiguous in the current PEP.  In one
> example it appears that there is a lock associated with each
> unqualified use of the synchronize keyword; in another, it seems that
> unqualified uses in the same class share a lock.
>
> Please try to explain the semantics of named and unnamed synchronize
> calls entirely in terms of code that would work in current Python,
> without using English (other than "this code is equivalent to that
> code").

Here is a (hopefully) clearer snippet I am working on in the revision:

        class SynchronizedCounter:

            def __init__(self):
                self.counter = 0
                self.counter_lock = thread.allocate_lock()

            def increment(self):
                self.counter_lock.acquire()
                try:
                    self.counter += 1
                finally:
                    self.counter_lock.release()

in my mind I wanted to replace with:

        class SynchronizedCounter:

            def __init__(self):
                 self.counter = 0

            def increment(self):
                synchronize:
                    self.counter += 1

Is your question, What is the unqualified lock associated with, the
instance, the class, the method, the counter, or something else?  If it is
your question then the answer is I'm not sure now that I've thought about
it deeper.  Clearly the concept of the synchronization is around the
counter, although now I can see no way to associate that implicitly. 
Perhaps this is why Java does not have unqualified synchronized blocks and
maybe I should remove it in which case the previous code would be:

        class SynchronizedCounter:

            def __init__(self):
                 self.counter = 0

            def increment(self):
                synchronize self.counter:
                    self.counter += 1

> I'd also like to see how 'asynchronize' works with condition
> variables, which seem to be the most common use for temporarily
> unlocking.

I will look into that.

> (Your example of how code would do this without
> asynchronize has a bug, by the way; if the I/O operation raises an
> exception, the finally clause will attempt to release an already
> released lock.)

Yes I need another try/finally in there.  Thanks.

> I think the PEP would be clearer if it was considerably shorter and to
> the point, with fewer examples and a more exact specification.

Thanks for the advice, I will move my thinking in this direction.

-Michel


From michel@dialnetwork.com  Mon Jun 16 07:30:28 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Mon, 16 Jun 2003 01:30:28 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <87fzmbdn1e.fsf@acooke.org>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com>
 <87fzmbdn1e.fsf@acooke.org>
Message-ID: <34514.66.19.39.176.1055745028.squirrel@squirrel.dialnetwork.com>

>
> there is also discussion at the moment of thread-synchronisation on
> the stackless python list.  people were considering ideas related to
> futures and csp (influenced largely by the oz language, i think).

Thanks for the tip, I'll check those out.

> personal opinion: while java may be better than python in this respect
> i think there are much better solutions out there.

A better solution to synchronize threads, or a better solution to
concurrency in general?  Would this oz language be something like that?

-Michel



From rnd@onego.ru  Mon Jun 16 07:22:17 2003
From: rnd@onego.ru (Roman Suzi)
Date: Mon, 16 Jun 2003 10:22:17 +0400 (MSD)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34511.66.19.39.176.1055744689.squirrel@squirrel.dialnetwork.com>
Message-ID: <Pine.LNX.4.44.0306161016300.12911-100000@suzi.com.onego.ru>

On Mon, 16 Jun 2003, Michel Pelletier wrote:

>             def __init__(self):
>                  self.counter = 0
> 
>             def increment(self):
>                 synchronize:
>                     self.counter += 1

What about just adding a parameter to try operator?

             def increment(self):
                 try self.counter_lock:
                     self.counter += 1

- this will save from keyword and could also be used with
except part with, for example, se-syncronization outcomes
for some kinds of locks:

             def increment(self):
                 try self.counter_lock:
                     self.counter += 1
                 except SomeLockError:
                     bla-bla-bla
 
> Is your question, What is the unqualified lock associated with, the
> instance, the class, the method, the counter, or something else?  If it is
> your question then the answer is I'm not sure now that I've thought about
> it deeper.  Clearly the concept of the synchronization is around the
> counter, although now I can see no way to associate that implicitly. 
> Perhaps this is why Java does not have unqualified synchronized blocks and
> maybe I should remove it in which case the previous code would be:
> 
>         class SynchronizedCounter:
> 
>             def __init__(self):
>                  self.counter = 0
> 
>             def increment(self):
>                 synchronize self.counter:
>                     self.counter += 1
> 
> > I'd also like to see how 'asynchronize' works with condition
> > variables, which seem to be the most common use for temporarily
> > unlocking.
> 
> I will look into that.
> 
> > (Your example of how code would do this without
> > asynchronize has a bug, by the way; if the I/O operation raises an
> > exception, the finally clause will attempt to release an already
> > released lock.)
> 
> Yes I need another try/finally in there.  Thanks.
> 
> > I think the PEP would be clearer if it was considerably shorter and to
> > the point, with fewer examples and a more exact specification.
> 
> Thanks for the advice, I will move my thinking in this direction.
> 
> -Michel
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> 

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rnd@onego.ru -
 



From drifty@alum.berkeley.edu  Mon Jun 16 07:24:11 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Sun, 15 Jun 2003 23:24:11 -0700
Subject: [Python-Dev] Details on Python shutting down
Message-ID: <3EED628B.70201@ocf.berkeley.edu>

On bug #754449 I suspected something was being set to None by a person's 
app and ended up writing a trace function to catch when that happened. 
Time then stepped in and pointed out that the OP said when Python was 
shutting down and that globals are set to None during tear down which 
would explain the behavior.  He suggested I move this over to python-dev.

So, what exactly does Python do during shutdown?  I assume all objects 
get cleaned up and have their __del__ methods called if they have them. 
  Tim mentioned in the patch that Python "systematically sets 
module-global bindings to None".  So I assume this means that 
referencing *any* globals during shutdown just doesn't work since it 
might be None (which makes sense in the case of this bug report).  Is 
there any specific order to this teardown?  I remember Tim saying that 
in __del__ methods you had to have locally bound anything you needed to 
call since otherwise it could be gone when you need it.

Any words of wisdom here would be greatly appreciated.

-Brett



From tdelaney@avaya.com  Mon Jun 16 07:26:49 2003
From: tdelaney@avaya.com (Delaney, Timothy C (Timothy))
Date: Mon, 16 Jun 2003 16:26:49 +1000
Subject: [Python-Dev] New PEP: 319
Message-ID: <338366A6D2E2CA4C9DAEAE652E12A1DE796D89@au3010avexu1.global.avaya.com>

> From: Roman Suzi [mailto:rnd@onego.ru]
>=20
> What about just adding a parameter to try operator?
>=20
>              def increment(self):
>                  try self.counter_lock:
>                      self.counter +=3D 1
>=20
> - this will save from keyword and could also be used with
> except part with, for example, se-syncronization outcomes
> for some kinds of locks:
>=20
>              def increment(self):
>                  try self.counter_lock:
>                      self.counter +=3D 1
>                  except SomeLockError:
>                      bla-bla-bla

Hmm - so this is essentially the

initially:
    self.counter_lock.acquire()
try:
    ...
finally:
    self.counter_lock.release()

but with the condition that the "parameter" to try implement the =
Lockable interface (or something along those lines).

Interesting idea. Not sure about the syntax, but I think we could go =
somewhere with this.

Tim Delaney


From michel@dialnetwork.com  Mon Jun 16 07:51:02 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Mon, 16 Jun 2003 01:51:02 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <Pine.LNX.4.44.0306161016300.12911-100000@suzi.com.onego.ru>
References: <34511.66.19.39.176.1055744689.squirrel@squirrel.dialnetwork.com>
 <Pine.LNX.4.44.0306161016300.12911-100000@suzi.com.onego.ru>
Message-ID: <34533.66.19.39.176.1055746262.squirrel@squirrel.dialnetwork.com>

> On Mon, 16 Jun 2003, Michel Pelletier wrote:
>
>>             def __init__(self):
>>                  self.counter = 0
>>
>>             def increment(self):
>>                 synchronize:
>>                     self.counter += 1
>
> What about just adding a parameter to try operator?
>
>              def increment(self):
>                  try self.counter_lock:
>                      self.counter += 1

Because I would like to remove the user-visible lock entirely.  Although
your idea is similar to PEP 310, which proposes a new keyword "with".  I
think using the try keyword for this is inapropriate.

-Michel


From rnd@onego.ru  Mon Jun 16 07:43:47 2003
From: rnd@onego.ru (Roman Suzi)
Date: Mon, 16 Jun 2003 10:43:47 +0400 (MSD)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34533.66.19.39.176.1055746262.squirrel@squirrel.dialnetwork.com>
Message-ID: <Pine.LNX.4.44.0306161038480.12911-100000@suzi.com.onego.ru>

On Mon, 16 Jun 2003, Michel Pelletier wrote:

> > On Mon, 16 Jun 2003, Michel Pelletier wrote:
> >
> >>             def __init__(self):
> >>                  self.counter = 0
> >>
> >>             def increment(self):
> >>                 synchronize:
> >>                     self.counter += 1
> >
> > What about just adding a parameter to try operator?
> >
> >              def increment(self):
> >                  try self.counter_lock:
> >                      self.counter += 1
> 
> Because I would like to remove the user-visible lock entirely.  Although
> your idea is similar to PEP 310, which proposes a new keyword "with".  I
> think using the try keyword for this is inapropriate.

But is it such a good idea to do? What if critical section is at two or
more different places at once? How will you deal with

              def increment(self):
                  try self.counter_lock:
                      self.counter += 1

              def decrement(self):
                  try self.counter_lock:
                      self.counter -= 1

(Suppose, it's not simple or elegant to do it in one place:

              def change(self, delta=1):
                  try self.counter_lock:
                      self.counter += delta

)

As for with, it could be added as follows:

   try with lock:
     lalalala



 
> -Michel

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rnd@onego.ru -
 



From michel@dialnetwork.com  Mon Jun 16 08:19:19 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Mon, 16 Jun 2003 02:19:19 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <Pine.LNX.4.44.0306161038480.12911-100000@suzi.com.onego.ru>
References: <34533.66.19.39.176.1055746262.squirrel@squirrel.dialnetwork.com>
 <Pine.LNX.4.44.0306161038480.12911-100000@suzi.com.onego.ru>
Message-ID: <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>

> But is it such a good idea to do? What if critical section is at two or
> more different places at once? How will you deal with
>
>               def increment(self):
>                   try self.counter_lock:
>                       self.counter += 1

    def increment(self):
        synchronize self.counter:
            self.counter += 1
>
>               def decrement(self):
>                   try self.counter_lock:
>                       self.counter -= 1

    def decrement(self):
        synchronize self.counter:
            self.counter -= 1

> (Suppose, it's not simple or elegant to do it in one place:
>
>               def change(self, delta=1):
>                   try self.counter_lock:
>                       self.counter += delta

    def change(self, delta=1):
        synchronize self.counter:
            self.counter += data

No explicit lock is necessary.  Any object may be synchronized upon
(except, perhaps, None).  The first time an object is synchronized, a lock
is invisibly associated with it behind the scenes, you cannot (and should
not) access this lock.  The lock exists for the life of the object it
synchronizes.  When a synchronize block is entered, the lock is acquire()d
and and release()d when the block is exited.

Very similar to the way Java does it:

http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#255769

except that in addition I propose an 'asynchronize' keyword that is used
inside a synchronized block to temporarily unlock it to do, for example,
blocking IO, or any other blocking operation that does not require
synchronization.

-Michel


From martin@v.loewis.de  Mon Jun 16 08:09:46 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 16 Jun 2003 09:09:46 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <PDEDIFMNJCFOKJPHIFJNIEFNDNAA.jeffh@activestate.com>
References: <PDEDIFMNJCFOKJPHIFJNIEFNDNAA.jeffh@activestate.com>
Message-ID: <m3he6q7b2d.fsf@mira.informatik.hu-berlin.de>

"Jeff Hobbs" <jeffh@ActiveState.com> writes:

> Can someone explain to me why moving to UCS-4 is a good thing?  

Because it simplifies processing of non-BMP characters, as it restores
the property that you get one Unicode character per string index.

> What UCS-4 support are you looking for that doesn't seem to exist?

It crashes when fed non-BMP characters. In addition, it lacks a
configuration option, or any kind of documentation telling packagers
on how to build a UCS-4 Tcl/Tk.

> While Tcl is agnostic about non-BMP chars (all 2 of them ... ha ha),
> it does have correct UCS-4 support (not completely though with how
> RedHat patched it).  This has been discussed before briefly here:
> 
> https://sourceforge.net/tracker/?func=detail&aid=578030&group_id=10894&atid=
> 110894

Which of the follow-up messages do you consider reliable information
in this report? davygrvy comments appear to be irrelevant, as they
talk about Unicode 3.0, keithp likewise. Your own comment appears to
talk about possible future changes, instead of the current code.

> A Tcl_UniChar is 32-bits and TCL_UTF_MAX is 6 (normally it is 3),
> which represents the number of utf-8 bytes that are valid in sequence.

Is that current code, or future code? How can I select a UCS-4 build
during configuration? In what way is the supported mechanism different
from the one that Redhat uses?

> I do realize that correct handling on non-BMP characters requires
> some more work, but that is orthogonal to this issue.  While UCS-4
> opens up more code points to allow non-BMP chars, there are very few
> in that range at this point.  

I couldn't find definitive numbers on distribution over planes, but I
found the following numbers:
- Unicode 3.0 has 49194 assigned characters
  (http://www.unicode.org/versions/Unicode3.0.html)
- Unicode 4.0 has 96248 graphic characters
  (http://www.unicode.org/versions/Unicode4.0.0/)

I don't know how many of the new assignments are in the BMP, but it
appears that there are roughly as many assigned BMP characters as
there are assigned characters outside the BMP.

> The bigger issue is that in changing the basic Tcl_UniChar size, you
> break the binary compatability rules.  RH9 is the only
> version/distro to use 32-bit Tcl_UniChar, which breaks compatability
> with extensions build on other versions/distros.

Indeed. Python has added explicit mechanisms to detect such breakage,
by renaming all API functions depending on the width of a Unicode
character. That, atleast, allows to detect the breakage at import
time (missing symbols).

> Also, while Tcl can build and works just find with 32-bit
> Tcl_UniChar, but I don't recall testing Tk when I tested Tcl.
> Checking on a rebuild now, it does appear that Tk operates just
> fine.  However, it does consume a lot more memory.

When I tested it, I found that it would break very easily. I was using
the Redhat procedure, though, so I might have made something wrong.

> I finally found the source RPMs for Tcl that RH9 uses and checked
> out there patch.  It's not even correct.  You have to modify
> tcl/generic/regcustom.h as well to account for Tcl_UniChar being
> 32-bits.  

What is the specific change that one has to make? "You have to edit
multiple files to activate a feature" is a strange way of supporting
it...

> IOW, it's very annoying to me that someone at RedHat went
> blundering around in the dark making these modifications when it is
> fairly easy to find and communicate with the core developers on the
> what, how and why of doing things correctly.

Indeed. In the specific case, they made the Tcl change to support
UCS-4 Python, when it would have been cleaner, IMO, to fix
_tkinter. Alas, they did not contact us, either.

Regards,
Martin


From martin@v.loewis.de  Mon Jun 16 08:19:12 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 16 Jun 2003 09:19:12 +0200
Subject: [Python-Dev] Details on Python shutting down
In-Reply-To: <3EED628B.70201@ocf.berkeley.edu>
References: <3EED628B.70201@ocf.berkeley.edu>
Message-ID: <m3d6he7amn.fsf@mira.informatik.hu-berlin.de>

"Brett C." <bac@OCF.Berkeley.EDU> writes:

> So, what exactly does Python do during shutdown?  

Part of what happens is pythonrun.c:Py_Finalize.

> I assume all objects get cleaned up and have their __del__ methods
> called if they have them.

No. Python never explicitly destroys object. They end life solely by
having their refcount drop to zero.

> Tim mentioned in the patch that Python "systematically sets
> module-global bindings to None".  So I assume this means that
> referencing *any* globals during shutdown just doesn't work since it
> might be None (which makes sense in the case of this bug report).

No. It depends on the order of things. There may be globals which you
can refer to; other globals may have been zapped.

> Is there any specific order to this teardown?

To shutdown in general: yes, see Py_Finalize. The order of module
teardown is defined in import.c:PyImport_Cleanup. Modules are zapped
in the order in which PyDict_Next returns them (skipping
__builtins__).

> I remember Tim saying that in __del__ methods you had to have
> locally bound anything you needed to call since otherwise it could
> be gone when you need it.

It may be that in specific cases, you can be sure that things will be
there. In general, binding stuff in __del__ parameters or in self is a
good idea.

Regards,
Martin



From michel@dialnetwork.com  Mon Jun 16 09:00:25 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Mon, 16 Jun 2003 03:00:25 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <200306160158.h5G1w1a29648@pcp02138704pcs.reston01.va.comcast.net>
References: <34244.66.19.48.90.1055705382.squirrel@squirrel.dialnetwork.com><20030
 616014019.GA22785@panix.com>
 <200306160158.h5G1w1a29648@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <34565.66.19.50.158.1055750425.squirrel@squirrel.dialnetwork.com>

> I'd also like to see how 'asynchronize' works with condition
> variables, which seem to be the most common use for temporarily
> unlocking.

Hmm... I think the 'synchronize' keyword would make condition variables
simpler, because they would not need to be associated with their own lock,
or rather, the lock currently associated with them would not need to be
used.  Given the example in:

http://www.python.org/doc/current/lib/condition-objects.html

the psedo-code would become:

# Consume one item
synchronize cv:
    while not an_item_is_available():
        cv.wait()
    get_an_available_item()

# Produce one item
synchronize cv:
    make_an_item_available()
    cv.notify()

there is a problem here, however, and I *think* this is the question you
are asking.  The manual states " The wait() method releases the lock, and
then blocks until it is awakened by a notify() or notifyAll() call for the
same condition variable in another thread. Once awakened, it re-acquires
the lock and returns. It is also possible to specify a timeout. "

Is the question your asking, How does 'wait()' unlock a hidden lock? 
(FYI, Java does it by making all objects condition variables, wait,
notify, and notifyAll are methods of java.lang.Object)  Perhaps a __x__
method could provide access to the "hidden" lock for wait and asychronize
would not be used.  or, wait() could be changed to do nothing with the
lock and simply wait() inside an asynchronize block:

# Consume one item
synchronize cv:
    while not an_item_is_available():
        asynchronize:
            cv.wait()
    get_an_available_item()

-Michel


From Jack.Jansen@cwi.nl  Mon Jun 16 10:20:14 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Mon, 16 Jun 2003 11:20:14 +0200
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
Message-ID: <BD04FB82-9FDB-11D7-890B-0030655234CE@cwi.nl>

On Monday, Jun 16, 2003, at 09:19 Europe/Amsterdam, Michel Pelletier 
wrote:
> No explicit lock is necessary.  Any object may be synchronized upon
> (except, perhaps, None).  The first time an object is synchronized, a 
> lock
> is invisibly associated with it behind the scenes, you cannot (and 
> should
> not) access this lock.  The lock exists for the life of the object it
> synchronizes.  When a synchronize block is entered, the lock is 
> acquire()d
> and and release()d when the block is exited.

I think this is a bad idea, after pondering it for a while[*]. There 
will always be situations where you want to lock multiple objects, and 
before you know it you'll end up with extra objects that hold no data 
but only a lock. And then it would have been better to design the 
language feature that way in the first place. Explicit is better than 
implicit:-)

[*] I wondered for a while whether locking only a single object would 
maybe steer people away from potentially deadlocking code, but I 
believe it's the other way around: with explicit locks you actually 
have to think of the locks you need, whereas with implicit locks you 
don't, so you write deadlocking code more often.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman



From Anthony Baxter <anthony@interlink.com.au>  Mon Jun 16 06:36:56 2003
From: Anthony Baxter <anthony@interlink.com.au> (Anthony Baxter)
Date: Mon, 16 Jun 2003 15:36:56 +1000
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <PDEDIFMNJCFOKJPHIFJNIEFNDNAA.jeffh@activestate.com>
Message-ID: <200306160536.h5G5aubf022154@localhost.localdomain>

>>> "Jeff Hobbs" wrote
> My ears were ringing for this one, so I thought I'd add some comments.
> [exactly how RH screwed up Tcl/Tk]

It's probably worth also noting that it seems like the RH9 version of
tcl/tk leaks memory like a sieve. Running exmh, I see a leak of about
100Mbytes a day. So if you've got long running Tkinter processes, it'd
pay to keep an eye on the memory consumption...

Anthony

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



From walter@livinglogic.de  Mon Jun 16 12:51:52 2003
From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Mon, 16 Jun 2003 13:51:52 +0200
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306130052.h5D0qcf30211@pcp02138704pcs.reston01.va.comcast.net>
References: <200306130031.h5D0VCh16042@oma.cosc.canterbury.ac.nz> <200306130052.h5D0qcf30211@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <3EEDAF58.9070906@livinglogic.de>

Guido van Rossum wrote:

>>>There's a lot of C code out there that catches e.g. AttributeError and
>>>replaces it with a more specific error (e.g. BifurcationError("can't
>>>bifurcate the sploorg") replacing AttributeError("__bifurcate__").  I
>>>think this would cause end user confusion.
>>
>>But that is a different case. As I understand it, chaining would only
>>occur if a second exception was raised *before* the current exception
>>was caught -- e.g. if there's a bug in a piece of code in a finally
>>block that's being executed while unwinding to find an exception
>>handler.
> 
> Interesting..  I had never even thought of this case.  I thought
> chaining was specifically when catching an exception and raising
> another in its place.
> 
> To the people who came up with the idea, which is it?

I only though about the the case, where one exception is has already
been raised is replaced with another exception. Exceptions in
a finally clause is an interesting new scenario.

> (I can see an argument for both cases; maybe they should be supported
> using different system attributes on the exception object?)

Sounds reasonable. If we don't want the exception replacement case to
chain the exceptions automatically, we'd need this argument/attribute
in all exception constructors. For the finally cause the attribute
should be set by the exception machinery.

Bye,
    Walter Dörwald




From hfastjava@yahoo.com  Mon Jun 16 13:02:41 2003
From: hfastjava@yahoo.com (Hunter Peress)
Date: Mon, 16 Jun 2003 05:02:41 -0700 (PDT)
Subject: [Python-Dev] "%%s %s"%"hi"%ho" works here and not there
Message-ID: <20030616120241.7451.qmail@web41305.mail.yahoo.com>

In irc, I gave this unusually compact line as an answer to a slightly related question:
"%%s %s"%"hi"%ho" 

It ended up not working on a lot of the other users systems. "%%s %s"%a%b worked though on all i
believe.

Although this alone is probably too trivial to report to the list, it works on *my* 2.2.2 and 2.3b
and yet it worked no one elses.

Im on debian and the versions where this work are:

Python 2.2.2 (#1, Mar 21 2003, 23:01:54) 
[GCC 3.2.3 20030316 (Debian prerelease)]

and 

Python 2.3b1+ (#2, May 14 2003, 07:47:44) 
[GCC 3.2.3] on linux2


I've confirmed with a friend on debian unstable that his 2.2.3 and his 2.3b1 (built on june4) both
error out on the line above.

Anyway, i cant even figure out from the grammar whether this should or should not be allowed: 
http://python.org/doc/2.2/ref/strings.html


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


From guido@python.org  Mon Jun 16 13:12:57 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Jun 2003 08:12:57 -0400
Subject: [Python-Dev] On the possibility of "optimizing" range() calls in
 for-loops
In-Reply-To: "Your message of Sun, 15 Jun 2003 23:59:33 EDT."
 <00d401c333bb$b2519da0$125ffea9@oemcomputer>
References: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>
 <00d401c333bb$b2519da0$125ffea9@oemcomputer>
Message-ID: <200306161212.h5GCCvx30562@pcp02138704pcs.reston01.va.comcast.net>

> The SF patch manager has a workable implementation of your idea:
> 
>     www.python.org/sf/738094  for i in range(N) optimization 
> 
> The jury is still out on whether it is an elegant, brilliant patch or
> a horrendous hack.

And why couldn't it be both? :-)

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


From mwh@python.net  Mon Jun 16 13:16:39 2003
From: mwh@python.net (Michael Hudson)
Date: Mon, 16 Jun 2003 13:16:39 +0100
Subject: [Python-Dev] "%%s %s"%"hi"%ho" works here and not there
In-Reply-To: <20030616120241.7451.qmail@web41305.mail.yahoo.com> (Hunter
 Peress's message of "Mon, 16 Jun 2003 05:02:41 -0700 (PDT)")
References: <20030616120241.7451.qmail@web41305.mail.yahoo.com>
Message-ID: <2mr85ufc9k.fsf@starship.python.net>

Hunter Peress <hfastjava@yahoo.com> writes:

> In irc, I gave this unusually compact line as an answer to a slightly related question:
> "%%s %s"%"hi"%ho" 
>

That line contains an odd number of double quotes and no escaping
characters.  How could it work?

>>> "%%s %s"%"hi"%"ho"
'ho hi'

is fine (% is left associative).

Cheers,
M.

-- 
  I also fondly recall Paris because that's where I learned to
  debug Zetalisp while drunk.                          -- Olin Shivers


From jepler@unpythonic.net  Mon Jun 16 13:37:55 2003
From: jepler@unpythonic.net (Jeff Epler)
Date: Mon, 16 Jun 2003 07:37:55 -0500
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
References: <34533.66.19.39.176.1055746262.squirrel@squirrel.dialnetwork.com> <Pine.LNX.4.44.0306161038480.12911-100000@suzi.com.onego.ru> <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
Message-ID: <20030616123752.GL23024@unpythonic.net>

On Mon, Jun 16, 2003 at 02:19:19AM -0500, Michel Pelletier wrote:
>     def change(self, delta=1):
>         synchronize self.counter:
<             self.counter += delta # typo corrected by jepler
> 
> No explicit lock is necessary.  Any object may be synchronized upon
> (except, perhaps, None).  The first time an object is synchronized, a lock
> is invisibly associated with it behind the scenes, you cannot (and should
> not) access this lock.  The lock exists for the life of the object it
> synchronizes.  When a synchronize block is entered, the lock is acquire()d
> and and release()d when the block is exited.

I don't see how this can possibly work.  It looks like self.counter is
an int, so the statement
    synchronize self.counter: ...
must be using some particular int (say, 3) for purposes of
synchronization.  What sense does this make?  (and where can you store
the lock, since an int is immutable and can't have new attributes
created?) On the other hand, if the thing you're locking is the counter
attribute of slot (and ignoring for a moment where the lock is stored)
then what if self.counter is a list but id(self.counter) ==
id(globallist)?  Then the 'synchronize' will not prevent these two
snippets from executing at the same time:
    def change(self, delta=1):
        synchronize self.counter:
            for i in range(delta):
                self.counter.append(i)

    synchronize globallist:
        globallist.pop()
globallist.pop() could now see a different item than delta-1

My other question concerns the 'asynchronize' portion of your proposal.
Is this from Java, or is it your own innovation?  I didn't turn up
anything about it in several web searches, but I'm not familiar enough
with java to know for sure.

Jeff


From skip@pobox.com  Mon Jun 16 13:47:22 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 16 Jun 2003 07:47:22 -0500
Subject: [Python-Dev] "%%s %s"%"hi"%ho" works here and not there
In-Reply-To: <20030616120241.7451.qmail@web41305.mail.yahoo.com>
References: <20030616120241.7451.qmail@web41305.mail.yahoo.com>
Message-ID: <16109.48218.533223.459663@montanaro.dyndns.org>

    Hunter> In irc, I gave this unusually compact line as an answer to a
    Hunter> slightly related question: "%%s %s"%"hi"%ho"

    Hunter> It ended up not working on a lot of the other users
    Hunter> systems. "%%s %s"%a%b worked though on all i believe.

I don't see you your hi/ho example can work as written, since there are an
odd number of quotes.  Adding an extra quote in the obvious place makes it
work for me:

    >>> "%%s %s"%"hi"%ho" 
      File "<stdin>", line 1
        "%%s %s"%"hi"%ho" 
                         ^
    SyntaxError: EOL while scanning single-quoted string
    >>> "%%s %s"%"hi"%"ho" 
    'ho hi'

You can get carried away with the concept as well:

    >>> "%%%%s %%s %s"%"hi"%"ho"%"hum" 
    'hum ho hi'
    >>> "%%%%%%%%s %%%%s %%s %s"%"hi"%"ho"%"hum"%"harvey" 
    'harvey hum ho hi'

Should people be tempted to do this sort of thing on a regular basis, I
suggest you avoid it unless you're competing in an obfuscated Python
contest.  I've used the technique (though with just with two levels of
interpolation!) a few times and always found it a bit challenging to go back
and read later.  I think it's better to split into multiple statements using
a temporary variable so it's obvious what gets substituted when (also, a
little whitespace never hurts):

    >>> fmt = "%%s %s" % "hi"
    >>> fmt
    '%s hi'
    >>> fmt % "ho"
    'ho hi'

Skip


From guido@python.org  Mon Jun 16 13:58:28 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Jun 2003 08:58:28 -0400
Subject: [Python-Dev] "%%s %s"%"hi"%ho" works here and not there
In-Reply-To: "Your message of Mon, 16 Jun 2003 05:02:41 PDT."
 <20030616120241.7451.qmail@web41305.mail.yahoo.com>
References: <20030616120241.7451.qmail@web41305.mail.yahoo.com>
Message-ID: <200306161258.h5GCwSW30719@pcp02138704pcs.reston01.va.comcast.net>

> In irc, I gave this unusually compact line as an answer to a slightly related question:
> "%%s %s"%"hi"%ho" 

Stop wasting our time.  You have a loose trailing quote.

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


From hfastjava@yahoo.com  Mon Jun 16 14:20:08 2003
From: hfastjava@yahoo.com (Hunter Peress)
Date: Mon, 16 Jun 2003 06:20:08 -0700 (PDT)
Subject: [Python-Dev] i meant "%%s %s"%"hi"%"ho" , but the issue is literally IRC
In-Reply-To: <200306161258.h5GCwSW30719@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20030616132008.13329.qmail@web41314.mail.yahoo.com>

i even stopped for 20 minutes *before* sending the email out, and i realized i made a mistake with
the missing quote, sorry that i sent it to the list. 

so i really meant: 
"%%s %s"%"hi"%"ho" 

maybe 10 months ago i discovered that IRC doesnt deal with %'s well so it was coming through as:



"%s %s"%"hi"%"ho" 

ach!!!!   anyway, just now, i wanted some more backup data from #python and i finally realized
that it was IRC all along. im very sorry :-).

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


From hfastjava@yahoo.com  Mon Jun 16 14:21:38 2003
From: hfastjava@yahoo.com (Hunter Peress)
Date: Mon, 16 Jun 2003 06:21:38 -0700 (PDT)
Subject: [Python-Dev] Doc issue http://python.org/doc/2.2/api/iterator.html
In-Reply-To: <200306161258.h5GCwSW30719@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20030616132138.80133.qmail@web41304.mail.yahoo.com>

http://python.org/doc/2.2/api/iterator.html 

heh... i was fooling around with the C api (and benchmarks show that the work i did was
unneccessary as pscyo 1.0 really kicks ass..so i dropped the C).

anyway, you'll notice that some of the latex is not converted.

 

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


From mcherm@mcherm.com  Mon Jun 16 15:00:47 2003
From: mcherm@mcherm.com (Michael Chermside)
Date: Mon, 16 Jun 2003 07:00:47 -0700
Subject: [Python-Dev] New PEP: 319
Message-ID: <1055772047.3eedcd8f0ec82@mcherm.com>

Michel Pelletier writes:
   [...]
> No explicit lock is necessary.  Any object may be synchronized upon
> (except, perhaps, None).
   [...]


In my opinion, this is one of the glaring *flaws* of the java threading
and synchronization model. Locks are entities of their own, to be used
when synchronization is needed. There does NOT need to be a lock
associated with each and every object in the system (even if, as an
implementation detail, that lock isn't created unless it is used). If
a programmer needs to synchronize, they should THINK about what exactly
needs to be synchronized with what, and create an appropriately named
lock. Explicit is better than implicit. Making it "easy" for programmers
who use threads by making unnecessary for them to think about details
like which lock is used for what synchronization, is almost certainly
NOT doing them a favor... instead, it's just inviting subtle, hard-to-
find bugs.

-- Michael Chermside
 


From michel@dialnetwork.com  Mon Jun 16 16:16:55 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Mon, 16 Jun 2003 10:16:55 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <BD04FB82-9FDB-11D7-890B-0030655234CE@cwi.nl>
References: <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
 <BD04FB82-9FDB-11D7-890B-0030655234CE@cwi.nl>
Message-ID: <34574.66.19.37.116.1055776615.squirrel@squirrel.dialnetwork.com>

>
> On Monday, Jun 16, 2003, at 09:19 Europe/Amsterdam, Michel Pelletier
> wrote:
>> No explicit lock is necessary.  Any object may be synchronized upon
>> (except, perhaps, None).  The first time an object is synchronized, a
>> lock
>> is invisibly associated with it behind the scenes, you cannot (and
>> should
>> not) access this lock.  The lock exists for the life of the object it
>> synchronizes.  When a synchronize block is entered, the lock is
>> acquire()d
>> and and release()d when the block is exited.
>
> I think this is a bad idea, after pondering it for a while[*]. There
> will always be situations where you want to lock multiple objects,

Can you be more explicit?  I'm not sure I understand.  In Python as it is
now, you cannot "lock" an object, only a lock (unless the object is like a
condition variable, which proxies a lock).  Any association between that
lock and any number of objects is a concept that must be maintained in
your head and visually in your code.  PEP 319 proposes automating the
simplest and  most common cases of these associations.

> and
> before you know it you'll end up with extra objects that hold no data
> but only a lock

What are extra objects?  If your objects are no longer necessary they are
garbage collected like all others, including their locks.  is your concern
memory consumption?

>. And then it would have been better to design the
> language feature that way in the first place. Explicit is better than
> implicit:-)
>
> [*] I wondered for a while whether locking only a single object would
> maybe steer people away from potentially deadlocking code, but I
> believe it's the other way around: with explicit locks you actually
> have to think of the locks you need, whereas with implicit locks you
> don't, so you write deadlocking code more often.

I belive the reverse, synchronize will reduce user error and deadlocking
code.  with explicit locks programmers will forget, or become confused,
with when and how to explicitly lock and unlock.  'synchronize' locks at
the beginning of the block and unlocks at the end.  There is no
forgetting.

-Michel

-Michel


From aahz@pythoncraft.com  Mon Jun 16 16:04:27 2003
From: aahz@pythoncraft.com (Aahz)
Date: Mon, 16 Jun 2003 11:04:27 -0400
Subject: [Python-Dev] Details on Python shutting down
In-Reply-To: <3EED628B.70201@ocf.berkeley.edu>
References: <3EED628B.70201@ocf.berkeley.edu>
Message-ID: <20030616150427.GA22638@panix.com>

On Sun, Jun 15, 2003, Brett C. wrote:
> 
> So, what exactly does Python do during shutdown?  I assume all
> objects get cleaned up and have their __del__ methods called if they
> have them.  Tim mentioned in the patch that Python "systematically
> sets module-global bindings to None".  So I assume this means that
> referencing *any* globals during shutdown just doesn't work since it
> might be None (which makes sense in the case of this bug report).  Is
> there any specific order to this teardown?  I remember Tim saying that
> in __del__ methods you had to have locally bound anything you needed
> to call since otherwise it could be gone when you need it.

Prior to Python 2.3, gc.collect() was not called by the shutdown
process, so fewer objects got cleaned up.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From michel@dialnetwork.com  Mon Jun 16 16:24:52 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Mon, 16 Jun 2003 10:24:52 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <20030616123752.GL23024@unpythonic.net>
References: <34533.66.19.39.176.1055746262.squirrel@squirrel.dialnetwork.com>
 <Pine.LNX.4.44.0306161038480.12911-100000@suzi.com.onego.ru>
 <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
 <20030616123752.GL23024@unpythonic.net>
Message-ID: <34576.66.19.37.116.1055777092.squirrel@squirrel.dialnetwork.com>

> On Mon, Jun 16, 2003 at 02:19:19AM -0500, Michel Pelletier wrote:
>>     def change(self, delta=1):
>>         synchronize self.counter:
> <             self.counter += delta # typo corrected by jepler
>>
>> No explicit lock is necessary.  Any object may be synchronized upon
>> (except, perhaps, None).  The first time an object is synchronized, a
>> lock
>> is invisibly associated with it behind the scenes, you cannot (and
>> should
>> not) access this lock.  The lock exists for the life of the object it
>> synchronizes.  When a synchronize block is entered, the lock is
>> acquire()d
>> and and release()d when the block is exited.
>
> I don't see how this can possibly work.  It looks like self.counter is
> an int, so the statement
>     synchronize self.counter: ...
> must be using some particular int (say, 3) for purposes of
> synchronization.  What sense does this make?

Hmm good point, integer objects are a special case, they  are shared and
are thus a bad example.  Perhaps only instances should be synchronizable.

>  (and where can you store
> the lock, since an int is immutable and can't have new attributes
> created?)

that's up to the implementation.  Lock association does not effect
mutability.

> On the other hand, if the thing you're locking is the counter
> attribute of slot (and ignoring for a moment where the lock is stored)
> then what if self.counter is a list but id(self.counter) ==
> id(globallist)?

If they have the same id() they are the same object and thus the same
associated lock. the below code will be prevented from executing at the
same time.

>  Then the 'synchronize' will not prevent these two
> snippets from executing at the same time:
>     def change(self, delta=1):
>         synchronize self.counter:
>             for i in range(delta):
>                 self.counter.append(i)
>
>     synchronize globallist:
>         globallist.pop()
> globallist.pop() could now see a different item than delta-1
>
> My other question concerns the 'asynchronize' portion of your proposal.
> Is this from Java, or is it your own innovation?  I didn't turn up
> anything about it in several web searches, but I'm not familiar enough
> with java to know for sure.

Yep that's my idea; but I doubt there's no precedence for it.

-Michel


From jeremy@zope.com  Mon Jun 16 16:07:16 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: 16 Jun 2003 11:07:16 -0400
Subject: [Python-Dev] Exception masking/chaining
In-Reply-To: <200306130052.h5D0qcf30211@pcp02138704pcs.reston01.va.comcast.net>
References: <200306130031.h5D0VCh16042@oma.cosc.canterbury.ac.nz>
 <200306130052.h5D0qcf30211@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <1055776036.13162.11.camel@slothrop.zope.com>

On Thu, 2003-06-12 at 20:52, Guido van Rossum wrote:
> > But that is a different case. As I understand it, chaining would only
> > occur if a second exception was raised *before* the current exception
> > was caught -- e.g. if there's a bug in a piece of code in a finally
> > block that's being executed while unwinding to find an exception
> > handler.
> 
> Interesting..  I had never even thought of this case.  I thought
> chaining was specifically when catching an exception and raising
> another in its place.
> 
> To the people who came up with the idea, which is it?

I don't know if I participated in the earlier email discussions.  I do
remember some conversations in the office here.  I'm interested in
chaining to convert one kind of exception to another.

I was debugging a case that is illustrated by the example below.

>>> class Foo:
...     pass
... 
>>> {}.update(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: keys

I expected a TypeError in this case, because I've passed an object to
dict.update that couldn't possibly work.  I looked at changing the code
to generated a TypeError, but I realized that the AttributeError keys is
a lot more helpful for a developer who wants to understand what went
wrong.

I think chained exceptions could make this error message a bit clearer. 
The AttributeError could become an attribute (previous?) of the
TypeError that is ultimately raised.

I think there are relatively few places where chaining exceptions makes
sense, so I'd like to see an explicit API for chaining.  Code that wants
to create chained exceptions would explicitly opt in.

Jeremy




From skip@pobox.com  Mon Jun 16 16:27:41 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 16 Jun 2003 10:27:41 -0500
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34574.66.19.37.116.1055776615.squirrel@squirrel.dialnetwork.com>
References: <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
 <BD04FB82-9FDB-11D7-890B-0030655234CE@cwi.nl>
 <34574.66.19.37.116.1055776615.squirrel@squirrel.dialnetwork.com>
Message-ID: <16109.57837.895257.685136@montanaro.dyndns.org>

    Jack> There will always be situations where you want to lock multiple
    Jack> objects,

    Michel> Can you be more explicit?  I'm not sure I understand.  

I have a multi-threaded XML-RPC server which, among lots of other bits of
data maintains some "top 50" data (top 50 cities searched for, top 50
performers searched for, etc).  Update time for that data is very fast
relative to much of the other data maintained by the server.  Rather than
create a lock for each of the various "top 50" objects, I simply created a
single top50_lock object and acquire and release it around manipulation of
any of the various bits related to that stuff.  Having a single lock means
my code is simpler at the possible extra cost of only allowing a single
thread into a larger chunk of code.  OTOH, had I created multiple locks,
performance might actually have gotten worse due to lock acquisition/release
overhead.

Obviously I could have done things differently.  I could have coalesced all
the top 50 data into a single object and locked it or created a separate
lock for each item.  Still, I agree with Jack that there are plenty of
situations where you use one lock to lock multiple objects.  (Consider the
Python GIL as another example. ;-)

Skip


From skip@pobox.com  Mon Jun 16 16:38:37 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 16 Jun 2003 10:38:37 -0500
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34574.66.19.37.116.1055776615.squirrel@squirrel.dialnetwork.com>
References: <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
 <BD04FB82-9FDB-11D7-890B-0030655234CE@cwi.nl>
 <34574.66.19.37.116.1055776615.squirrel@squirrel.dialnetwork.com>
Message-ID: <16109.58493.768223.8396@montanaro.dyndns.org>

Missed this on the first read:

    Michel> with explicit locks programmers will forget, or become confused,
    Michel> with when and how to explicitly lock and unlock.  'synchronize'
    Michel> locks at the beginning of the block and unlocks at the end.
    Michel> There is no forgetting.

You still need to remember to 'synchronize' access to the data.  That's the
bigger problem in my mind.

It seems to me that the more locks I need to manage, the harder it will be
to identify potential deadlock situations.  With fewer locks (I use five
RLock objects and a Queue in my XML-RPC server) I think it's easier to
compartmentalize functionality in my feeble brain and avoid deadlock, with
some potential loss of execution overlap.

Skip


From jeff@hobbs.org  Mon Jun 16 17:11:14 2003
From: jeff@hobbs.org (Jeff Hobbs)
Date: Mon, 16 Jun 2003 09:11:14 -0700
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <200306160536.h5G5aubf022154@localhost.localdomain>
Message-ID: <AEEJJLFGECCKDONDOCKEMEJPGAAA.jeffh@activestate.com>

> From: Anthony Baxter
> >>> "Jeff Hobbs" wrote
> > My ears were ringing for this one, so I thought I'd add some comments.
> > [exactly how RH screwed up Tcl/Tk]
> 
> It's probably worth also noting that it seems like the RH9 version of
> tcl/tk leaks memory like a sieve. Running exmh, I see a leak of about
> 100Mbytes a day. So if you've got long running Tkinter processes, it'd
> pay to keep an eye on the memory consumption...

Leaks, or just consumes?  I mentioned in my previous email that it
appears that Tk does consume a lot of memory when using 32-bit
Tcl_UniChars.  Tk isn't completely leak-free, but it doesn't have
any known major leaks.  I don't know why increasing the size of a
Tcl_UniChar would start creating leaks (although it does seem to
consume more memory than it should just for that increase in data
size ... so it does require more examination).

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/


From jeff@hobbs.org  Mon Jun 16 17:40:26 2003
From: jeff@hobbs.org (Jeff Hobbs)
Date: Mon, 16 Jun 2003 09:40:26 -0700
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <m3he6q7b2d.fsf@mira.informatik.hu-berlin.de>
Message-ID: <AEEJJLFGECCKDONDOCKEEEKAGAAA.jeffh@activestate.com>

> From: martin@v.loewis.de
> Jeff Hobbs writes:
> 
> > Can someone explain to me why moving to UCS-4 is a good thing?  
> 
> Because it simplifies processing of non-BMP characters, as it restores
> the property that you get one Unicode character per string index.

Right, fair enough, that's all well understood - when you have to
deal with characters between U+10000 and U+10FFFF.  It was only
recently that such characters existed in more than a sprinkling.

> > A Tcl_UniChar is 32-bits and TCL_UTF_MAX is 6 (normally it is 3),
> > which represents the number of utf-8 bytes that are valid in sequence.
> 
> Is that current code, or future code? How can I select a UCS-4 build
> during configuration? In what way is the supported mechanism different
> from the one that Redhat uses?

There is no "supported" UCS-4 mode for Tcl.  You have to hand-twiddle
the sources, knowing where to poke.  I can make the changes for 8.5
that allow for an easy configuration option to compile in UCS-4 mode.
I suppose I could also back-port it to 8.4.4.  That won't address the
fact that we've never validated non-BMP support.

> I couldn't find definitive numbers on distribution over planes, but I
> found the following numbers:
> - Unicode 3.0 has 49194 assigned characters
>   (http://www.unicode.org/versions/Unicode3.0.html)
> - Unicode 4.0 has 96248 graphic characters
>   (http://www.unicode.org/versions/Unicode4.0.0/)

Right, and Unicode 4.0 is fresh out of diapers.  You can't even get
the regular code charts yet, you have to view the 4.0 beta ones.  With
4.0 the non-BMP finally gets a notable amount of characters, but they
are fairly weird ones that I'd be surprised to find a public font for.
You can see them at:
	http://www.unicode.org/charts/u40-beta.html
They are the Linear B Syllabary on down.

> > The bigger issue is that in changing the basic Tcl_UniChar size, you
> > break the binary compatability rules.  RH9 is the only
> > version/distro to use 32-bit Tcl_UniChar, which breaks compatability
> > with extensions build on other versions/distros.
> 
> Indeed. Python has added explicit mechanisms to detect such breakage,
> by renaming all API functions depending on the width of a Unicode
> character. That, atleast, allows to detect the breakage at import
> time (missing symbols).

Tcl could do this, but we were very much taken by surprise that it
was pushed to use UCS-4 at all.

> > Checking on a rebuild now, it does appear that Tk operates just
> > fine.  However, it does consume a lot more memory.
> 
> When I tested it, I found that it would break very easily. I was using
> the Redhat procedure, though, so I might have made something wrong.

Can you feed me some sample scripts offline to test with?

> > I finally found the source RPMs for Tcl that RH9 uses and checked
> > out there patch.  It's not even correct.  You have to modify
> > tcl/generic/regcustom.h as well to account for Tcl_UniChar being
> > 32-bits.  
> 
> What is the specific change that one has to make? "You have to edit
> multiple files to activate a feature" is a strange way of supporting
> it...

Ha ha ... well, I did say it was never properly supported.  That
noone bothered to ask how to do it correctly when that was clear is
not a good thing.  What you have to do is modify generic/tcl.h to
set TCL_UTF_MAX to 6, typedef Tcl_UniChar as unsigned int (or
wchar_t is what RH used), and then modify the bottom of
generic/regcustom.h, where you will see 3 lines that need mods for
the change in size of CHR (which is Tcl_UniChar for the RE).

Of course, that's what I think is needed.  It should probably then
get extended tests for more characters and further expectations.
We should probably add a tcl_platform(unicharSize) var or something
so that users at the Tcl level know this as well.  Again, this is
only something that I have tinkered with - not extensively tested.

Regards,

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/


From michel@dialnetwork.com  Mon Jun 16 17:59:07 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Mon, 16 Jun 2003 11:59:07 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <16109.57837.895257.685136@montanaro.dyndns.org>
References: <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
 <BD04FB82-9FDB-11D7-890B-0030655234CE@cwi.nl>
 <34574.66.19.37.116.1055776615.squirrel@squirrel.dialnetwork.com>
 <16109.57837.895257.685136@montanaro.dyndns.org>
Message-ID: <34583.66.19.38.196.1055782747.squirrel@squirrel.dialnetwork.com>

Hi Skip!

>     Jack> There will always be situations where you want to lock multiple
>     Jack> objects,
>
>     Michel> Can you be more explicit?  I'm not sure I understand.
>
> I have a multi-threaded XML-RPC server which, among lots of other bits of
> data maintains some "top 50" data (top 50 cities searched for, top 50
> performers searched for, etc).  Update time for that data is very fast
> relative to much of the other data maintained by the server.  Rather than
> create a lock for each of the various "top 50" objects, I simply created a
> single top50_lock object and acquire and release it around manipulation of
> any of the various bits related to that stuff.  Having a single lock means
> my code is simpler at the possible extra cost of only allowing a single
> thread into a larger chunk of code.  OTOH, had I created multiple locks,
> performance might actually have gotten worse due to lock
> acquisition/release
> overhead.
>
> Obviously I could have done things differently.  I could have coalesced
> all
> the top 50 data into a single object and locked it or created a separate
> lock for each item.

    synchronize item:

would create a (hidden) lock for each item for you.  Wouldn't this solve
your problem of no two threads changing one item?  or do changes to any
one top 50 item *require* locking all 50?  If they are independent that
this is exactly the purpose PEP 319 serves.

>  Still, I agree with Jack that there are plenty of
> situations where you use one lock to lock multiple objects.  (Consider the
> Python GIL as another example. ;-)

Isn't the interpreter one object in this case?  Does the GIL lock anything
else other than the interpreter?

-Michel


From fdrake@acm.org  Mon Jun 16 18:18:32 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Mon, 16 Jun 2003 13:18:32 -0400
Subject: [Python-Dev] Doc issue http://python.org/doc/2.2/api/iterator.html
In-Reply-To: <20030616132138.80133.qmail@web41304.mail.yahoo.com>
References: <200306161258.h5GCwSW30719@pcp02138704pcs.reston01.va.comcast.net>
 <20030616132138.80133.qmail@web41304.mail.yahoo.com>
Message-ID: <16109.64488.265243.121726@grendel.zope.com>

Hunter Peress writes:
 > anyway, you'll notice that some of the latex is not converted.

This was fixed for Python 2.2.1.  You should be able to use
http://www.python.org/doc/current/ for any Python in the 2.2.x series
(at least until Python 2.3 is released).


  -Fred

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


From python@rcn.com  Mon Jun 16 18:19:07 2003
From: python@rcn.com (Raymond Hettinger)
Date: Mon, 16 Jun 2003 13:19:07 -0400
Subject: [Python-Dev] Doc issue http://python.org/doc/2.2/api/iterator.html
References: <20030616132138.80133.qmail@web41304.mail.yahoo.com>
Message-ID: <001101c3342b$653954c0$125ffea9@oemcomputer>

From: "Hunter Peress" <hfastjava@yahoo.com>

> http://python.org/doc/2.2/api/iterator.html 
> 
> heh... i was fooling around with the C api (and benchmarks show that the work i did was
> unneccessary as pscyo 1.0 really kicks ass..so i dropped the C).
> 
> anyway, you'll notice that some of the latex is not converted.

Thanks for pointing this out.
I'll get it fixed-up.
Next time, please file a bug report on SF instead of posting here.


Raymond Hettinger

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################


From jeffh@ActiveState.com  Mon Jun 16 19:29:41 2003
From: jeffh@ActiveState.com (Jeff Hobbs)
Date: Mon, 16 Jun 2003 11:29:41 -0700
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <m3he6q7b2d.fsf@mira.informatik.hu-berlin.de>
Message-ID: <PDEDIFMNJCFOKJPHIFJNCEGJDNAA.jeffh@activestate.com>

> From: martin@v.loewis.de
> Jeff Hobbs writes:
>
> > Can someone explain to me why moving to UCS-4 is a good thing?
>
> Because it simplifies processing of non-BMP characters, as it restores
> the property that you get one Unicode character per string index.
	...
> > While Tcl is agnostic about non-BMP chars (all 2 of them ... ha ha),
> > it does have correct UCS-4 support (not completely though with how
> > RedHat patched it).  This has been discussed before briefly here:
> >
> >
>
https://sourceforge.net/tracker/?func=detail&aid=578030&group_id=10894&atid=
110894
>
> Which of the follow-up messages do you consider reliable information
> in this report? davygrvy comments appear to be irrelevant, as they
> talk about Unicode 3.0, keithp likewise. Your own comment appears to
> talk about possible future changes, instead of the current code.

BTW, I mentioned this because I'm not sure that the reasoning behind
moving to a 32-bit integral type was due to RHs desire to support the
extra chars in Unicode 4 (after all, without shipping fonts to display
them ... what's the point?).  Keith Packard, who submitted the bug
report (RFE really) is one of the major XFree maintainers (err ... I
guess that's xwin now).  In any case, he wanted to allow 32-bit in X
in part for ease of processing, advantages of word alignment, and
other things.

IOW, I'm not really sure that this was all done to support UCS-4
specifically, although that may have been a consideration.

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/



From michel@dialnetwork.com  Mon Jun 16 19:55:09 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Mon, 16 Jun 2003 13:55:09 -0500 (CDT)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34576.66.19.37.116.1055777092.squirrel@squirrel.dialnetwork.com>
References: <34533.66.19.39.176.1055746262.squirrel@squirrel.dialnetwork.com>
 <Pine.LNX.4.44.0306161038480.12911-100000@suzi.com.onego.ru>
 <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
 <20030616123752.GL23024@unpythonic.net>
 <34576.66.19.37.116.1055777092.squirrel@squirrel.dialnetwork.com>
Message-ID: <34635.63.164.149.143.1055789709.squirrel@squirrel.dialnetwork.com>

>> I don't see how this can possibly work.  It looks like self.counter is
>> an int, so the statement
>>     synchronize self.counter: ...
>> must be using some particular int (say, 3) for purposes of
>> synchronization.  What sense does this make?
>
> Hmm good point, integer objects are a special case, they  are shared and
> are thus a bad example.  Perhaps only instances should be synchronizable.
>
>>  (and where can you store
>> the lock, since an int is immutable and can't have new attributes
>> created?)
>
> that's up to the implementation.  Lock association does not effect
> mutability.

I should add that I am experimenting with this in Jython, not CPython
which is why I said it's up to the implementation.  I immagine CPython
would add some unitialized behind-the-scenes pointer to a lock object and
lazily initialize and lock it when the object is first sychronized.  Any
subsequent asynchronizing or sychronizing would use this lock until the
object is garbage collected.

>> On the other hand, if the thing you're locking is the counter
>> attribute of slot (and ignoring for a moment where the lock is stored)
>> then what if self.counter is a list but id(self.counter) ==
>> id(globallist)?
>
> If they have the same id() they are the same object and thus the same
> associated lock. the below code will be prevented from executing at the
> same time.

Ah I'm going over all the emails I got today for my next revision and
sorry I missed where you said "attribute of the slot" the first time I
read it.  You meant, I gather, sychronizing on the slot and not the value
it stores.  Sorry to confuse things.  I do not think sychronizing on the
slot is the right thing (as I said above).

Thanks for everyones comments, please keep sending them if you have them.

-Michel


From rnd@onego.ru  Mon Jun 16 19:37:52 2003
From: rnd@onego.ru (Roman Suzi)
Date: Mon, 16 Jun 2003 22:37:52 +0400 (MSD)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34583.66.19.38.196.1055782747.squirrel@squirrel.dialnetwork.com>
Message-ID: <Pine.LNX.4.44.0306162158220.2561-100000@rnd.onego.ru>

On Mon, 16 Jun 2003, Michel Pelletier wrote:

>> Obviously I could have done things differently.  I could have coalesced
>> all
>> the top 50 data into a single object and locked it or created a separate
>> lock for each item.
>
>    synchronize item:
>
>would create a (hidden) lock for each item for you.  Wouldn't this solve
>your problem of no two threads changing one item?  or do changes to any
>one top 50 item *require* locking all 50?  If they are independent that
>this is exactly the purpose PEP 319 serves.

Oh no... I have not thought about locking objects, but locking places of a
program from multiple entry. I do not think the whole business of locking
_objects_ is appropriate to do. And thus I think Michel should think about the
implementation of his locking infrastructure. Even in high-level terms
implementation seems fuzzy and prone to semantics misunderstandings.
And this became clear to me when all this discussion of top50 was
presented.

I think anonymous locking is bad idea. Locking based on syntactic
containment (?) is also problematic. The only obvious way is 
to have explicit lock.

Thus I understand that 

syncronize:
   lalala

means only that it could not be re-entered from other thread and
not that all objects encountered inside are "locked".

This makes

syncronize self.counter:
   self.counter += 1

looking silly.

And I must also say that examples from the PEP aren't convincing. All that
implicit locking on target objects is looking like magic. And as we know
explicit is better than implicit (*). This way I will never know why my
program consumed so much memory and it takes so long to make simple things:
and the answer is implicit locks lurking here and there, with every object.

(*sorry for being the first person to use the word implicit in the PEP
name ;-)

One more solution is to have same target-object blocks but with explicit
instantiation:

   def lalala(self, queue):
     syncronize AdHocLock(queue):
       do_something(queue)

The main idea here AdHocLock being a singleton which creates
a lock and shepherds a dict of locks, keys of which are for example
weak refs to objects.

So, making 

   def lalala(self, number):
     syncronize AdHocLock(number):
       do_something(number)

is no contradiction. We can as well have a constant:

   def lalala3(self):
     syncronize AdHocLock(3):
       do_something

This is not so good because it creates and maintains global structure (locks)
and thus two modules could have a conflict over same object id or number.

Much better solution, IMHO, is to use traditional explicit locks: no need for
new keywords, no need to worry that objects will have a shadow of accompanying
locks.

Sincerely yours, Roman Suzi
-- 
rnd@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3



From pedronis@bluewin.ch  Mon Jun 16 20:07:26 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Mon, 16 Jun 2003 21:07:26 +0200
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34635.63.164.149.143.1055789709.squirrel@squirrel.dialnetw
 ork.com>
References: < <34576.66.19.37.116.1055777092.squirrel@squirrel.dialnetwork.com>
 <34533.66.19.39.176.1055746262.squirrel@squirrel.dialnetwork.com>
 <Pine.LNX.4.44.0306161038480.12911-100000@suzi.com.onego.ru>
 <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
 <20030616123752.GL23024@unpythonic.net>
 <34576.66.19.37.116.1055777092.squirrel@squirrel.dialnetwork.com>
Message-ID: <5.2.1.1.0.20030616205221.02a634a8@pop.bluewin.ch>

Look here, if want a (short) summary of current thinking on java sync 
primitives from Java side:

<http://www.jcp.org/en/jsr/detail?id=166>

Python is already doing things alright, it already has got the higher-level 
constructs.

'synchronized' makes sense on methods to have thread-safe data structures. 
The rest of Java synchronization facilities should really be used to 
construct higher-level tools.

I think 'with' is very likely a worthy addition. And maybe something along 
the lines of:

class C(object,Synchronizable):

   def meth(self,...) [syncmethod]:
     ...

I'm very skeptical about syncrhonize/asynchronize and implicit locks 
associated/able with all objects.

regards.

At 13:55 16.06.2003 -0500, Michel Pelletier wrote:

> >> I don't see how this can possibly work.  It looks like self.counter is
> >> an int, so the statement
> >>     synchronize self.counter: ...
> >> must be using some particular int (say, 3) for purposes of
> >> synchronization.  What sense does this make?
> >
> > Hmm good point, integer objects are a special case, they  are shared and
> > are thus a bad example.  Perhaps only instances should be synchronizable.
> >
> >>  (and where can you store
> >> the lock, since an int is immutable and can't have new attributes
> >> created?)
> >
> > that's up to the implementation.  Lock association does not effect
> > mutability.
>
>I should add that I am experimenting with this in Jython, not CPython
>which is why I said it's up to the implementation.  I immagine CPython
>would add some unitialized behind-the-scenes pointer to a lock object and
>lazily initialize and lock it when the object is first sychronized.  Any
>subsequent asynchronizing or sychronizing would use this lock until the
>object is garbage collected.
>
> >> On the other hand, if the thing you're locking is the counter
> >> attribute of slot (and ignoring for a moment where the lock is stored)
> >> then what if self.counter is a list but id(self.counter) ==
> >> id(globallist)?
> >
> > If they have the same id() they are the same object and thus the same
> > associated lock. the below code will be prevented from executing at the
> > same time.
>
>Ah I'm going over all the emails I got today for my next revision and
>sorry I missed where you said "attribute of the slot" the first time I
>read it.  You meant, I gather, sychronizing on the slot and not the value
>it stores.  Sorry to confuse things.  I do not think sychronizing on the
>slot is the right thing (as I said above).
>
>Thanks for everyones comments, please keep sending them if you have them.
>
>-Michel
>
>_______________________________________________
>Python-Dev mailing list
>Python-Dev@python.org
>http://mail.python.org/mailman/listinfo/python-dev



From skip@pobox.com  Mon Jun 16 20:13:11 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 16 Jun 2003 14:13:11 -0500
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34583.66.19.38.196.1055782747.squirrel@squirrel.dialnetwork.com>
References: <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
 <BD04FB82-9FDB-11D7-890B-0030655234CE@cwi.nl>
 <34574.66.19.37.116.1055776615.squirrel@squirrel.dialnetwork.com>
 <16109.57837.895257.685136@montanaro.dyndns.org>
 <34583.66.19.38.196.1055782747.squirrel@squirrel.dialnetwork.com>
Message-ID: <16110.5831.265591.246553@montanaro.dyndns.org>

    >> I have a multi-threaded XML-RPC server which, among lots of other
    >> bits of data maintains some "top 50" data (top 50 cities searched
    >> for, top 50 performers searched for, etc).  Update time for that data
    >> is very fast relative to much of the other data maintained by the
    >> server.

    Michel>     synchronize item:

    Michel> would create a (hidden) lock for each item for you.  Wouldn't
    Michel> this solve your problem of no two threads changing one item?  or
    Michel> do changes to any one top 50 item *require* locking all 50?  If
    Michel> they are independent that this is exactly the purpose PEP 319
    Michel> serves.

I can see I wasn't clear in my original post.  Let me be more concrete.  I
have a class with several objects with store information about the top 50
searches for musicians and cities on the Mojam and Musi-Cal websites:

    class DBServer(genericserver.GenericServer):
        doratings = 1
        poolsize = 5

        def __init__(self, address, handlerclass):
            genericserver.GenericServer.__init__(self, address, handlerclass)

            self.conn_pool = Queue.Queue(self.poolsize)
            self.init_locks()
            ...
            self.top_50_perfs = {}
            self.top_50_cities = {}
            self.top_50_mojam = {}
            self.top_50_musi_cal = {}
            ...

Instead of creating a lock to protect each of those four objects I create a
single lock for that purpose:

        def init_locks(self):
            self.sql_lock = threading.RLock()
            self.query_lock = threading.RLock()
            self.top_50_lock = threading.RLock()
            self.namemap_lock = threading.RLock()
            self.dump_lock = threading.RLock()

Your proposal would suggest I (implicitly) create a lock for each of those
top_50_* dictionaries.  I think my code would be more complex.  I think this
is precisely the sort of case Jack was alluding to with his "one lock,
multiple objects" case.  In this case it's overkill for me to create
separate locks for each object because access times for those data are
fast.  There isn't likely to be any contention for that lock.

For my applications I would be more than happy with a more succinct (and
safe) way to write:

    lock.acquire()
    try:
        block
    finally:
        lock.release()

I don't really care what the syntax is, but I think implicit per-object
locks are unnecessary.

    >> Still, I agree with Jack that there are plenty of situations where
    >> you use one lock to lock multiple objects.  (Consider the Python GIL
    >> as another example. ;-)

    Michel> Isn't the interpreter one object in this case?  Does the GIL
    Michel> lock anything else other than the interpreter?

Depends on what level you look at it.  Sure, the interpreter is a single
object, but it's a very complex object which contains lots of other
subobjects.  There are lots of places in the Python code where assumptions
are made that because the GIL is being held, the (in)consistency of a
particular object at that point in time isn't crucial.  You know no other
thread can access that object right then because the GIL is held by the
currently executing thread.  As long as the object's state is made
consistent by the time you release the GIL you're golden.  In essence, the
GIL is Jack's "one lock, multiple objects" case taken to the extreme.

Skip



From jeremy@zope.com  Mon Jun 16 20:33:33 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: 16 Jun 2003 15:33:33 -0400
Subject: [Python-Dev] problem with assignment shadows builtin warning
Message-ID: <1055792013.13162.26.camel@slothrop.zope.com>

I ran into a problem with the new deprecation warning today.  When you
are doing package imports, Python uses setattr to populate the namespace
of the parent package.  That is, if you import A.B.C, Python does the
equiavalent of setattr(A, "B", A.B) and setattr(A.B, "C", A.B.C).

The result is that I get a bunch of deprecation warnings if my modules
shadow builtin names.  Module names that are also builtin names are
common in some work projects.  (Ouput from our test runner is at the end
of the message.)

Do we want to discourage the use of module names that overlap with
builtin names?  If so, we need a better error message, because if you go
to the line mentioned in the warning you won't see an obvious assignment
:-).

My initial reaction was that we should not have a deprecation warning
for this kind of shadowing, but I'm growing less comfortable about the
names.  I'd definitely complain about a top-level "import list"; I don't
know why it is any better as a module within a package.

Jeremy


/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/security/_protections.py:85: DeprecationWarning: assignment shadows builtin
  from persistence.list import PersistentList
/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/security/_protections.py:93: DeprecationWarning: assignment shadows builtin
  from persistence.dict import PersistentDict
/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/event/globalservice.py:22: DeprecationWarning: assignment shadows builtin
  from zope.interface.type import TypeRegistry
/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/ftp/__init__.py:22: DeprecationWarning: assignment shadows builtin
  from zope.app.interfaces.file import IReadFile, IWriteFile
/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zodb/storage/tests/test_demo.py:21: DeprecationWarning: assignment shadows builtin
  from zodb.storage.file import FileStorage
/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/event/subs.py:37: DeprecationWarning: assignment shadows builtin
  from zope.app.services.type import PersistentTypeRegistry
/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/browser/content/image.py:19: DeprecationWarning: assignment shadows builtin
  from zope.app.browser.content.file import FileUpload
/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/content/file.py:26: DeprecationWarning: assignment shadows builtin
  from zope.app.interfaces.content.file import IFile, IReadFile,
IFileContent
/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/content/image.py:18: DeprecationWarning: assignment shadows builtin
  from zope.app.content.file import File




From jeremy@zope.com  Mon Jun 16 20:53:19 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: 16 Jun 2003 15:53:19 -0400
Subject: [Python-Dev] problem with assignment shadows builtin warning
In-Reply-To: <1055792013.13162.26.camel@slothrop.zope.com>
References: <1055792013.13162.26.camel@slothrop.zope.com>
Message-ID: <1055793199.13160.41.camel@slothrop.zope.com>

On Mon, 2003-06-16 at 15:33, Jeremy Hylton wrote:
> My initial reaction was that we should not have a deprecation warning
> for this kind of shadowing, but I'm growing less comfortable about the
> names.  I'd definitely complain about a top-level "import list"; I don't
> know why it is any better as a module within a package.

Guido observed that a top-level "import list" does not generate a
warning.  So regardless of the propriety of naming a module in a package
"list", it should not generate a warning.  I guess someone needs to
patch the import code to manipulate the parent namespaces in a way that
won't generate an exception.

Jeremy




From pedronis@bluewin.ch  Mon Jun 16 20:59:36 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Mon, 16 Jun 2003 21:59:36 +0200
Subject: [Python-Dev] problem with assignment shadows builtin
 warning
In-Reply-To: <1055792013.13162.26.camel@slothrop.zope.com>
Message-ID: <5.2.1.1.0.20030616215004.02a634a8@pop.bluewin.ch>

I really think this thing need a PEP.

I think especially describing the future semantics of bultin lookup.

While I see that reusing builtin names is contrived (but we are not always 
disallowing that, for backward compability), I see the proposed approach as 
rather adhoc: you can't mess with a module builtins view unelss it already did.

regards.


At 15:33 16.06.2003 -0400, Jeremy Hylton wrote:
>I ran into a problem with the new deprecation warning today.  When you
>are doing package imports, Python uses setattr to populate the namespace
>of the parent package.  That is, if you import A.B.C, Python does the
>equiavalent of setattr(A, "B", A.B) and setattr(A.B, "C", A.B.C).
>
>The result is that I get a bunch of deprecation warnings if my modules
>shadow builtin names.  Module names that are also builtin names are
>common in some work projects.  (Ouput from our test runner is at the end
>of the message.)
>
>Do we want to discourage the use of module names that overlap with
>builtin names?  If so, we need a better error message, because if you go
>to the line mentioned in the warning you won't see an obvious assignment
>:-).
>
>My initial reaction was that we should not have a deprecation warning
>for this kind of shadowing, but I'm growing less comfortable about the
>names.  I'd definitely complain about a top-level "import list"; I don't
>know why it is any better as a module within a package.
>
>Jeremy
>
>
>/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/security/_protections.py:85: 
>DeprecationWarning: assignment shadows builtin
>   from persistence.list import PersistentList
>/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/security/_protections.py:93: 
>DeprecationWarning: assignment shadows builtin
>   from persistence.dict import PersistentDict
>/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/event/globalservice.py:22: 
>DeprecationWarning: assignment shadows builtin
>   from zope.interface.type import TypeRegistry
>/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/ftp/__init__.py:22: 
>DeprecationWarning: assignment shadows builtin
>   from zope.app.interfaces.file import IReadFile, IWriteFile
>/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zodb/storage/tests/test_demo.py:21: 
>DeprecationWarning: assignment shadows builtin
>   from zodb.storage.file import FileStorage
>/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/event/subs.py:37: 
>DeprecationWarning: assignment shadows builtin
>   from zope.app.services.type import PersistentTypeRegistry
>/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/browser/content/image.py:19: 
>DeprecationWarning: assignment shadows builtin
>   from zope.app.browser.content.file import FileUpload
>/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/content/file.py:26: 
>DeprecationWarning: assignment shadows builtin
>   from zope.app.interfaces.content.file import IFile, IReadFile,
>IFileContent
>/home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/content/image.py:18: 
>DeprecationWarning: assignment shadows builtin
>   from zope.app.content.file import File
>
>
>
>_______________________________________________
>Python-Dev mailing list
>Python-Dev@python.org
>http://mail.python.org/mailman/listinfo/python-dev



From nas@python.ca  Mon Jun 16 21:14:12 2003
From: nas@python.ca (Neil Schemenauer)
Date: Mon, 16 Jun 2003 13:14:12 -0700
Subject: [Python-Dev] problem with assignment shadows builtin warning
In-Reply-To: <1055793199.13160.41.camel@slothrop.zope.com>
References: <1055792013.13162.26.camel@slothrop.zope.com> <1055793199.13160.41.camel@slothrop.zope.com>
Message-ID: <20030616201411.GA10067@glacier.arctrix.com>

Jeremy Hylton wrote:
> I guess someone needs to patch the import code to manipulate the
> parent namespaces in a way that won't generate an exception.

The simplest fix is to operate on the dict directly rather than using
PyObject_SetAttrString on the module.  It's a little ugly because the it
looks like that import code isn't limited to operating on modules.  I
guess the patch would have to be something like

    if (PyModule_Check(mod)) {
        PyObject *dict = PyModule_GetDict(mod);
        if (!dict) {
            Py_XDECREF(m);
            m = NULL;
        }
        else if (PyDict_SetItemString(dict, subname, res) < 0) {
            Py_XDECREF(m);
            m = NULL;
        }
    }
    else {
        PyObject_SetAttrString(mod, subname, res) < 0) {
            Py_XDECREF(m);
            m = NULL;
        }
    }

Ugly.  Luckily that's the only PyObject_SetAttrString() in the import
code.

  Neil


From guido@python.org  Mon Jun 16 21:17:01 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Jun 2003 16:17:01 -0400
Subject: [Python-Dev] problem with assignment shadows builtin warning
In-Reply-To: Your message of "Mon, 16 Jun 2003 13:14:12 PDT."
 <20030616201411.GA10067@glacier.arctrix.com>
References: <1055792013.13162.26.camel@slothrop.zope.com> <1055793199.13160.41.camel@slothrop.zope.com>
 <20030616201411.GA10067@glacier.arctrix.com>
Message-ID: <200306162017.h5GKH1P17067@odiug.zope.com>

> The simplest fix is to operate on the dict directly rather than using
> PyObject_SetAttrString on the module.  It's a little ugly because the it
> looks like that import code isn't limited to operating on modules.  I
> guess the patch would have to be something like
> 
>     if (PyModule_Check(mod)) {
>         PyObject *dict = PyModule_GetDict(mod);
>         if (!dict) {
>             Py_XDECREF(m);
>             m = NULL;
>         }
>         else if (PyDict_SetItemString(dict, subname, res) < 0) {
>             Py_XDECREF(m);
>             m = NULL;
>         }
>     }
>     else {
>         PyObject_SetAttrString(mod, subname, res) < 0) {
>             Py_XDECREF(m);
>             m = NULL;
>         }
>     }
> 
> Ugly.  Luckily that's the only PyObject_SetAttrString() in the import
> code.

But it sounds like a good idea to check this in.  Please add a comment
like

/* Don't want to use PyObject_SetAttrString() because of warnings about
   overriding builtins when the submodule name happens to shadow a
   built-in */

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


From pedronis@bluewin.ch  Mon Jun 16 21:18:57 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Mon, 16 Jun 2003 22:18:57 +0200
Subject: [Python-Dev] problem with assignment shadows builtin
 warning
In-Reply-To: <1055793199.13160.41.camel@slothrop.zope.com>
References: <1055792013.13162.26.camel@slothrop.zope.com>
 <1055792013.13162.26.camel@slothrop.zope.com>
Message-ID: <5.2.1.1.0.20030616220023.02a75db0@pop.bluewin.ch>

At 15:53 16.06.2003 -0400, Jeremy Hylton wrote:
>On Mon, 2003-06-16 at 15:33, Jeremy Hylton wrote:
> > My initial reaction was that we should not have a deprecation warning
> > for this kind of shadowing, but I'm growing less comfortable about the
> > names.  I'd definitely complain about a top-level "import list"; I don't
> > know why it is any better as a module within a package.
>
>Guido observed that a top-level "import list" does not generate a
>warning.  So regardless of the propriety of naming a module in a package
>"list", it should not generate a warning.  I guess someone needs to
>patch the import code to manipulate the parent namespaces in a way that
>won't generate an exception.

so code like

<pkg/__init__.py>


def reveal():
   print list

</pkg/__init__.py>

if pkg has a list subpackage/module will show that we are cheating, after 
caching is implemented, wrt to the old global->builtins lookup rule, 
because after:

import pkg.list

pkg.__dict__['list'] will be a module

but

pkg.reveal() will print the list builtin.

regards. 



From guido@python.org  Mon Jun 16 21:23:03 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Jun 2003 16:23:03 -0400
Subject: [Python-Dev] problem with assignment shadows builtin warning
In-Reply-To: Your message of "Mon, 16 Jun 2003 22:18:57 +0200."
 <5.2.1.1.0.20030616220023.02a75db0@pop.bluewin.ch>
References: <1055792013.13162.26.camel@slothrop.zope.com> <1055792013.13162.26.camel@slothrop.zope.com>
 <5.2.1.1.0.20030616220023.02a75db0@pop.bluewin.ch>
Message-ID: <200306162023.h5GKN3e17113@odiug.zope.com>

> so code like
> 
> <pkg/__init__.py>
> 
> 
> def reveal():
>    print list
> 
> </pkg/__init__.py>
> 
> if pkg has a list subpackage/module will show that we are cheating, after 
> caching is implemented, wrt to the old global->builtins lookup rule, 
> because after:
> 
> import pkg.list
> 
> pkg.__dict__['list'] will be a module
> 
> but
> 
> pkg.reveal() will print the list builtin.

No, the parser should know about the subpackage...

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


From pedronis@bluewin.ch  Mon Jun 16 21:36:24 2003
From: pedronis@bluewin.ch (Samuele Pedroni)
Date: Mon, 16 Jun 2003 22:36:24 +0200
Subject: [Python-Dev] problem with assignment shadows builtin
 warning
In-Reply-To: <200306162023.h5GKN3e17113@odiug.zope.com>
References: <Your message of "Mon, 16 Jun 2003 22:18:57 +0200." <5.2.1.1.0.20030616220023.02a75db0@pop.bluewin.ch>
 <1055792013.13162.26.camel@slothrop.zope.com>
 <1055792013.13162.26.camel@slothrop.zope.com>
 <5.2.1.1.0.20030616220023.02a75db0@pop.bluewin.ch>
Message-ID: <5.2.1.1.0.20030616223041.02a75db0@pop.bluewin.ch>

At 16:23 16.06.2003 -0400, Guido van Rossum wrote:
> > so code like
> >
> > <pkg/__init__.py>
> >
> >
> > def reveal():
> >    print list
> >
> > </pkg/__init__.py>
> >
> > if pkg has a list subpackage/module will show that we are cheating, after
> > caching is implemented, wrt to the old global->builtins lookup rule,
> > because after:
> >
> > import pkg.list
> >
> > pkg.__dict__['list'] will be a module
> >
> > but
> >
> > pkg.reveal() will print the list builtin.
>
>No, the parser should know about the subpackage...

I'm not impressed, really, but I got the message, you are all for this plan.

regards. 



From jeremy@zope.com  Mon Jun 16 21:35:22 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: 16 Jun 2003 16:35:22 -0400
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <5.2.1.1.0.20030616205221.02a634a8@pop.bluewin.ch>
References: < <34576.66.19.37.116.1055777092.squirrel@squirrel.dialnetwork.com>
 <34533.66.19.39.176.1055746262.squirrel@squirrel.dialnetwork.com>
 <Pine.LNX.4.44.0306161038480.12911-100000@suzi.com.onego.ru>
 <34550.66.19.39.176.1055747959.squirrel@squirrel.dialnetwork.com>
 <20030616123752.GL23024@unpythonic.net>
 <34576.66.19.37.116.1055777092.squirrel@squirrel.dialnetwork.com>
 <5.2.1.1.0.20030616205221.02a634a8@pop.bluewin.ch>
Message-ID: <1055795722.13160.44.camel@slothrop.zope.com>

On Mon, 2003-06-16 at 15:07, Samuele Pedroni wrote:
> Python is already doing things alright, it already has got the higher-level 
> constructs.
> 
> 'synchronized' makes sense on methods to have thread-safe data structures. 
> The rest of Java synchronization facilities should really be used to 
> construct higher-level tools.
> 
> I think 'with' is very likely a worthy addition. And maybe something along 
> the lines of:
> 
> class C(object,Synchronizable):
> 
>    def meth(self,...) [syncmethod]:
>      ...
> 
> I'm very skeptical about syncrhonize/asynchronize and implicit locks 
> associated/able with all objects.

+1

Jeremy




From guido@python.org  Mon Jun 16 21:39:21 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Jun 2003 16:39:21 -0400
Subject: [Python-Dev] problem with assignment shadows builtin warning
In-Reply-To: Your message of "Mon, 16 Jun 2003 22:36:24 +0200."
 <5.2.1.1.0.20030616223041.02a75db0@pop.bluewin.ch>
References: <Your message of "Mon, 16 Jun 2003 22:18:57 +0200." <5.2.1.1.0.20030616220023.02a75db0@pop.bluewin.ch> <1055792013.13162.26.camel@slothrop.zope.com> <1055792013.13162.26.camel@slothrop.zope.com> <5.2.1.1.0.20030616220023.02a75db0@pop.bluewin.ch>
 <5.2.1.1.0.20030616223041.02a75db0@pop.bluewin.ch>
Message-ID: <200306162039.h5GKdLg17239@odiug.zope.com>

> >No, the parser should know about the subpackage...
> 
> I'm not impressed, really, but I got the message, you are all for this plan.

Well, what do *you* want to do instead?

Let's talk this over at Europython, when I'll have more time.

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


From martin@v.loewis.de  Mon Jun 16 21:57:07 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 16 Jun 2003 22:57:07 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <AEEJJLFGECCKDONDOCKEEEKAGAAA.jeffh@activestate.com>
References: <AEEJJLFGECCKDONDOCKEEEKAGAAA.jeffh@activestate.com>
Message-ID: <m3r85tspuk.fsf@mira.informatik.hu-berlin.de>

"Jeff Hobbs" <jeffh@ActiveState.com> writes:

> Right, and Unicode 4.0 is fresh out of diapers.  You can't even get
> the regular code charts yet, you have to view the 4.0 beta ones.  With
> 4.0 the non-BMP finally gets a notable amount of characters, but they
> are fairly weird ones that I'd be surprised to find a public font for.

Actually, Unicode 3.2 added most of them; Unicode 4.0 has only minor
additions. The biggest addition is the CJK unified ideographs in plane
2, which is of significance to a fifth of the world population,
potentially - these are all current characters (instead of being only
of scientific interest).

I agree that it will take a while to have fonts for these
available. However, unavailability of fonts should not stop us from
supporting such characters in the libraries. Characters must pass
through many processing steps before being rendered, and all of these
steps must work flawlessly. So I think it is a good thing to start
today, to have the application software ready by the time fonts become
available.

> > When I tested it, I found that it would break very easily. I was using
> > the Redhat procedure, though, so I might have made something wrong.
> 
> Can you feed me some sample scripts offline to test with?

Will do, but it may take some time. It was so obvious to me that this
is not at all officially supported that I did not bother reporting it,
or taking notes.

Regards,
Martin


From martin@v.loewis.de  Mon Jun 16 22:04:49 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 16 Jun 2003 23:04:49 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <PDEDIFMNJCFOKJPHIFJNCEGJDNAA.jeffh@activestate.com>
References: <PDEDIFMNJCFOKJPHIFJNCEGJDNAA.jeffh@activestate.com>
Message-ID: <m3n0ghsphq.fsf@mira.informatik.hu-berlin.de>

"Jeff Hobbs" <jeffh@ActiveState.com> writes:

> BTW, I mentioned this because I'm not sure that the reasoning behind
> moving to a 32-bit integral type was due to RHs desire to support the
> extra chars in Unicode 4 (after all, without shipping fonts to display
> them ... what's the point?). 

I guess a driving motivation is alignment with the C library, atleast
that is what drove me to add UCS-4 support to Python. On Unix,
traditionally, wchar_t, if interpreted as Unicode, is a four-byte data
type. The Unicode spec performed an interesting dance about that:
Unicode 2.0 claimed that it was outright non-conforming to use a
four-byte wchar_t for Unicode. Unicode 3.0 said "well, you
can". Unicode 3.2 now says "why not, it's a reasonable thing to do".

So for us in the Unix world, the impression is that the C library's
decision was always "right", and we are eager to support that
decision. For libraries such as iconv, there is a performance
advantage gained from matching the interpreter's Unicoode type with
the system's wchar_t.

Apart from that, there is also the feeling that ISO 10646 got it right
and the Unicode consortium got it wrong. You really do need more than
64k code points if you want to unify all writing systems. From that
viewpoint, UTF-16 is an ugly hack, which should be avoided whereever
possible.

Regards,
Martin



From paul@prescod.net  Mon Jun 16 22:29:00 2003
From: paul@prescod.net (Paul Prescod)
Date: Mon, 16 Jun 2003 14:29:00 -0700
Subject: [Python-Dev] RE: PEP-317
In-Reply-To: <20030610172610.C2153@tibia.amotlpaa.bogus>
References: <1055253130.3ee5e28ab7650@mcherm.com> <200306101411.h5AEBWg13102@odiug.zope.com> <20030610142302.GA26466@panix.com> <20030610172610.C2153@tibia.amotlpaa.bogus>
Message-ID: <3EEE369C.3020508@prescod.net>

Steven Taschuk wrote:
> Quoth Aahz:
>   [...]
> 
>>                raise Found()
>>except Found:
> 
>   [...]
> 
>>I find that extra set of parentheses unnecessary and ugly.  It implies a
>>callable where it's not really being used that way, [...]
> 
> 
> In
>     raise Found
> Found *is* being used as a callable under the hood; an instance of
> Found is created implicitly.  You just happen not to care about
> that instance.

Yes, I think that this is precisely the reason that I don't like 
implicit instantiation. The syntax can put the user in the wrong mental 
model. An object _is_ being created. Python has an object instantiation 
syntax. It is unclear to me what you gain by avoiding the syntax used 
for object instantiation everywhere else.

  Paul Prescod



From paul@prescod.net  Mon Jun 16 22:55:57 2003
From: paul@prescod.net (Paul Prescod)
Date: Mon, 16 Jun 2003 14:55:57 -0700
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <200306111630.h5BGU7O31508@odiug.zope.com>
References: <1055330845.3ee7121d0c36c@mcherm.com> <200306111313.h5BDDTj20704@pcp02138704pcs.reston01.va.comcast.net>              <20030611103103.C1157@tibia.amotlpaa.bogus> <200306111630.h5BGU7O31508@odiug.zope.com>
Message-ID: <3EEE3CED.9050000@prescod.net>

Guido van Rossum wrote:
>>>I've now read the PEP, and it simply fails to explain why implicit
>>>instantiation sucks so badly as to require all this pain.  The
>>>arguments of readability and consistency are pretty mild suckage IMO.
>>
>>My next question, then, is whether those arguments are strong
>>enough to justify, for example, recommending against implicit
>>instantiation in PEP 8, or changing the Tutorial's examples.
> 
> 
> I think not.  This is something that each project may decide for
> itself.  But I'm at most -0 on this.

The tutorial[1] implies but does not state that there are two syntaxes 
and implies but does not state that they are basically the same. Or one 
could get the implication that built-in exceptions use one syntax and 
user-defined ones use the other.

I think that consistency is important to pedagogy and therefore feel 
that it should consistently use one syntax or the other. I wish Guido 
would pronounce that one is better than the other so that the software 
in the library could also migrate towards being pedagogically helpful. 
But if not, at least the tutorial can be internally consistent.

  Paul Prescod

[1] http://www.python.org/doc/current/tut/node10.html



From greg@cosc.canterbury.ac.nz  Mon Jun 16 23:27:30 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 17 Jun 2003 10:27:30 +1200 (NZST)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34574.66.19.37.116.1055776615.squirrel@squirrel.dialnetwork.com>
Message-ID: <200306162227.h5GMRUq24587@oma.cosc.canterbury.ac.nz>

Michel Pelletier <michel@dialnetwork.com>:

> I belive the reverse, synchronize will reduce user error and deadlocking
> code.  with explicit locks programmers will forget, or become confused,
> with when and how to explicitly lock and unlock.  'synchronize' locks at
> the beginning of the block and unlocks at the end.  There is no
> forgetting.

It may prevent you from forgetting to release a lock, which
is probably a very useful thing, but there are other ways that
deadlocks can occur, such as when you need to acquire multiple
locks and aren't careful what order you acquire them in.
Not having to think explicitly about locks may increase the
frequency of that kind of problem.

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


From greg@cosc.canterbury.ac.nz  Mon Jun 16 23:40:48 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 17 Jun 2003 10:40:48 +1200 (NZST)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34576.66.19.37.116.1055777092.squirrel@squirrel.dialnetwork.com>
Message-ID: <200306162240.h5GMem524666@oma.cosc.canterbury.ac.nz>

Michel Pelletier <michel@dialnetwork.com>:

> Hmm good point, integer objects are a special case, they  are shared and
> are thus a bad example.  Perhaps only instances should be
> synchronizable.

In the presence of new-style classes, how do you define an "instance"?

Anyway, the problem here isn't what kind of object was used, it's the
way the programmer used it (i.e. locking on an object that wasn't
going to stay around for the duration of the operation). I can't
really see a way of preventing this kind of stupidity by restricting
what types of objects can be locked -- you can lose a reference to any
type of object.

Maybe this is an argument against having implicit lock objects? If the
programmer has to explicitly create and keep track of the lock object,
he might look after it a bit more carefully.

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


From greg@cosc.canterbury.ac.nz  Tue Jun 17 00:44:55 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 17 Jun 2003 11:44:55 +1200 (NZST)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <Pine.LNX.4.44.0306162158220.2561-100000@rnd.onego.ru>
Message-ID: <200306162344.h5GNisL24805@oma.cosc.canterbury.ac.nz>

Roman Suzi <rnd@onego.ru>:

> I have not thought about locking objects, but locking places of a
> program from multiple entry.

If we're to have implicit lock objects, this is perhaps the
right way to think about it. But the locking needs to apply
to more than just one code block. Consider

  def increment(self):
    synchronize:
      self.count += 1

  def decrement(self):
    synchronize:
      self.count -= 1

If the two statements are synchronized independently, this
will not work.

I think the right level to synchronize at is a whole class:

  synchronized class Counter:

    def __init__(self):
      self.counter = 0

    def increment(self):
      self.count += 1

    def decrement(self):
      self.count -= 1

the semantics being that each instance of Counter gets
its own lock object, and the lock is acquired before any
method in it is entered and released when it is exited.

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


From Anthony Baxter <anthony@interlink.com.au>  Tue Jun 17 01:38:23 2003
From: Anthony Baxter <anthony@interlink.com.au> (Anthony Baxter)
Date: Tue, 17 Jun 2003 10:38:23 +1000
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <AEEJJLFGECCKDONDOCKEMEJPGAAA.jeffh@activestate.com>
Message-ID: <200306170038.h5H0cNop001497@localhost.localdomain>

>>> "Jeff Hobbs" wrote
> Leaks, or just consumes?  I mentioned in my previous email that it
> appears that Tk does consume a lot of memory when using 32-bit
> Tcl_UniChars.  Tk isn't completely leak-free, but it doesn't have
> any known major leaks.  I don't know why increasing the size of a
> Tcl_UniChar would start creating leaks (although it does seem to
> consume more memory than it should just for that increase in data
> size ... so it does require more examination).

After 2 1/2 days it's using 250Mbytes of RAM. There's a slow but 
steady increase continually across the time it's running. That's
without loading any HTML or any weird stuff - just text.

Anthony


From guido@python.org  Tue Jun 17 02:16:27 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 16 Jun 2003 21:16:27 -0400
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: "Your message of Mon, 16 Jun 2003 14:55:57 PDT."
 <3EEE3CED.9050000@prescod.net>
References: <1055330845.3ee7121d0c36c@mcherm.com>
 <200306111313.h5BDDTj20704@pcp02138704pcs.reston01.va.comcast.net>
 <20030611103103.C1157@tibia.amotlpaa.bogus>
 <200306111630.h5BGU7O31508@odiug.zope.com> <3EEE3CED.9050000@prescod.net>
Message-ID: <200306170116.h5H1GR015550@pcp02138704pcs.reston01.va.comcast.net>

[Guido]
> > I think not.  This is something that each project may decide for
> > itself.  But I'm at most -0 on this.

[Paul Prescod]
> The tutorial[1] implies but does not state that there are two syntaxes 
> and implies but does not state that they are basically the same. Or one 
> could get the implication that built-in exceptions use one syntax and 
> user-defined ones use the other.
> 
> I think that consistency is important to pedagogy and therefore feel 
> that it should consistently use one syntax or the other. I wish Guido 
> would pronounce that one is better than the other so that the software 
> in the library could also migrate towards being pedagogically helpful. 
> But if not, at least the tutorial can be internally consistent.

If there can be only one, then

  raise Exception()

should be it.

>   Paul Prescod
> 
> [1] http://www.python.org/doc/current/tut/node10.html

I think parts of this were written at different times.  It should
either explain the equivalence between

  raise Foo, bar

and

  raise Foo(bar)

(without going into the subtleties of what happens when bar is a Foo
instance or a tuple) or use the latter exclusively.  But I think that
it's fine at least to keep the examples that don't instantiate
explicitly, maybe explaining that

  raise KeyboardError

is short for

  raise KeyboardError()

(again, without going into the details of how the system "knows" that
-- that's not the task of the tutorial).

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


From gus.tabares@verizon.net  Tue Jun 17 02:18:25 2003
From: gus.tabares@verizon.net (Gus Tabares)
Date: Mon, 16 Jun 2003 21:18:25 -0400
Subject: [Python-Dev] IDLE bug?
Message-ID: <LFEJJJNJEBIGPEPEPLIPOEICCAAA.gus.tabares@verizon.net>

Hey all,

	Does anyone have an issue trying to get the 'Save Copy As...' control keys
to work in IDLE under Windows? (Alt+Shift+S) I'm not sure if this is the
right place to post bugs about IDLE. I've tested this on 4+ machines and it
did not work on all of them. Maybe this is already a known issue? Is anyone
else experiencing this?


Thanks,
Gus



From kbk@shore.net  Tue Jun 17 02:45:15 2003
From: kbk@shore.net (Kurt B. Kaiser)
Date: Mon, 16 Jun 2003 21:45:15 -0400
Subject: [Python-Dev] IDLE bug?
In-Reply-To: <LFEJJJNJEBIGPEPEPLIPOEICCAAA.gus.tabares@verizon.net> ("Gus
 Tabares"'s message of "Mon, 16 Jun 2003 21:18:25 -0400")
References: <LFEJJJNJEBIGPEPEPLIPOEICCAAA.gus.tabares@verizon.net>
Message-ID: <m3y901zdck.fsf@float.attbi.com>

"Gus Tabares" <gus.tabares@verizon.net> writes:

> 	Does anyone have an issue trying to get the 'Save Copy As...'
> control keys to work in IDLE under Windows? (Alt+Shift+S) I'm not
> sure if this is the right place to post bugs about IDLE. I've tested
> this on 4+ machines and it did not work on all of them. Maybe this
> is already a known issue? Is anyone else experiencing this?

Hm.  We've had nearly a thousand downloads of IDLEfork Windows
installers and no one has reported this until now.

But it appears that all the keystroke bindings using the "Classic
Windows" keyset which involve the Shift Key don't work!

(I use the Unix bindings)

Thanks for the report!


The best place to post bugs is on the Sourceforge Tracker

http://sourceforge.net/tracker/?group_id=9579&atid=109579


Maybe you could post a bug there.


The second best thing is to mention it on the idle-dev mail list at

http://mail.python.org/mailman/listinfo/idle-dev

__
KBK



From Jack.Jansen@cwi.nl  Tue Jun 17 10:01:38 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 17 Jun 2003 11:01:38 +0200
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <34574.66.19.37.116.1055776615.squirrel@squirrel.dialnetwork.com>
Message-ID: <4E301B33-A0A2-11D7-A0E8-0030655234CE@cwi.nl>

Most points have been addressed by Skip and Greg and others already, but
there's one I'd like to elaborate a little on:

On Monday, Jun 16, 2003, at 17:16 Europe/Amsterdam, Michel Pelletier 
wrote:
>> [*] I wondered for a while whether locking only a single object would
>> maybe steer people away from potentially deadlocking code, but I
>> believe it's the other way around: with explicit locks you actually
>> have to think of the locks you need, whereas with implicit locks you
>> don't, so you write deadlocking code more often.
>
> I belive the reverse, synchronize will reduce user error and 
> deadlocking
> code.  with explicit locks programmers will forget, or become confused,
> with when and how to explicitly lock and unlock.

The problem is if one piece of code has
	synchronise a:
		...
		synchronise b:
			...
and somewhere else you have
	synchronise b:
		...
		synchronise a:
			...

If you use fine-grained locking this is something you always have to be 
aware of.
In C-class languages it requires only discipline (don't call any 
subroutines
outside of your module while holding a lock, basically), in Python you 
can forget it
because every single statement or expression can be calling out all 
over the
place.

Note that this same problem turns up with Greg's "synchronised class" 
idea: if the
language makes locking easy people will overuse it and it will come 
back to bite you
(or, probably, a user of your module).
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman



From Paul.Moore@atosorigin.com  Tue Jun 17 10:24:58 2003
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Tue, 17 Jun 2003 10:24:58 +0100
Subject: [Python-Dev] New PEP: 319
Message-ID: <16E1010E4581B049ABC51D4975CEDB880113DB68@UKDCX001.uk.int.atosorigin.com>

From: Michael Chermside [mailto:mcherm@mcherm.com]
> Michel Pelletier writes:
>   [...]
>> No explicit lock is necessary.  Any object may be synchronized upon
>> (except, perhaps, None).
>   [...]

> In my opinion, this is one of the glaring *flaws* of the java =
threading
> and synchronization model. Locks are entities of their own, to be used
> when synchronization is needed. There does NOT need to be a lock
> associated with each and every object in the system (even if, as an
> implementation detail, that lock isn't created unless it is used). If
> a programmer needs to synchronize, they should THINK about what =
exactly
> needs to be synchronized with what, and create an appropriately named
> lock. Explicit is better than implicit. Making it "easy" for =
programmers
> who use threads by making unnecessary for them to think about details
> like which lock is used for what synchronization, is almost certainly
> NOT doing them a favor... instead, it's just inviting subtle, hard-to-
> find bugs.

I agree entirely. Thank you for putting it so well.

Paul.


From neal@metaslash.com  Tue Jun 17 14:57:22 2003
From: neal@metaslash.com (Neal Norwitz)
Date: Tue, 17 Jun 2003 09:57:22 -0400
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Objectslistobject.c,2.153,2.154
In-Reply-To: <006901c334d4$63f7c840$125ffea9@oemcomputer>
References: <E19S8fH-0007zx-00@sc8-pr-cvs1.sourceforge.net>
 <3EEF0907.6040900@livinglogic.de> <1055853119.3599.2.camel@anthem>
 <006901c334d4$63f7c840$125ffea9@oemcomputer>
Message-ID: <20030617135722.GL12316@epoch.metaslash.com>

Moving to python-dev.

On Tue, Jun 17, 2003 at 09:28:50AM -0400, Raymond Hettinger wrote:
> 
> I suppose we could have more debate after the fact,
> but this one seems straight-forward enough:
> 
> * discussed on comp.lang.python
> * had an RFE on SF
> * has clear use cases
> * got a +1 from Guido
> * is backwards compatible
> * matches the signature of str.index() and unicode.index()
> * matches the search technique for regular expressions
> * was a relatively simple coding change
> * checked in with thorough tests

While overall I think the idea is worthwhile, I have two concerns:
 * the doc wasn't updated
 * negative indices are handled differently:

        >>> 'abc'.split().index('a', -3)
        Traceback (most recent call last):
          File "<stdin>", line 1, in ?
        ValueError: list.index(x): x not in list
        >>> 'abc'.index('a', -3)
        0

Neal

> ----- Original Message ----- 
> From: "Barry Warsaw" <barry@python.org>
> 
> This seems like a pretty significant change to Python's API (or at least
> one of its more common built-ins).  Given that Python 2.3 is in beta,
> I'm wondering how wise it is to add this feature.  I'm sure I missed the
> python-dev debate about it <wink>.


From walter@livinglogic.de  Tue Jun 17 15:26:17 2003
From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Tue, 17 Jun 2003 16:26:17 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Objectslistobject.c,2.153,2.154
In-Reply-To: <20030617135722.GL12316@epoch.metaslash.com>
References: <E19S8fH-0007zx-00@sc8-pr-cvs1.sourceforge.net> <3EEF0907.6040900@livinglogic.de> <1055853119.3599.2.camel@anthem> <006901c334d4$63f7c840$125ffea9@oemcomputer> <20030617135722.GL12316@epoch.metaslash.com>
Message-ID: <3EEF2509.4080208@livinglogic.de>

Neal Norwitz wrote:

> Moving to python-dev.
> 
> [...]
> While overall I think the idea is worthwhile, I have two concerns:
>  * the doc wasn't updated
>  * negative indices are handled differently:
> 
>         >>> 'abc'.split().index('a', -3)
>         Traceback (most recent call last):
>           File "<stdin>", line 1, in ?
>         ValueError: list.index(x): x not in list
>         >>> 'abc'.index('a', -3)
>         0
> 
> Neal

I'm working on a fix for this.

Bye,
    Walter Dörwald



From walter@livinglogic.de  Tue Jun 17 15:37:09 2003
From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Tue, 17 Jun 2003 16:37:09 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Objectslistobject.c,2.153,2.154
In-Reply-To: <3EEF2509.4080208@livinglogic.de>
References: <E19S8fH-0007zx-00@sc8-pr-cvs1.sourceforge.net> <3EEF0907.6040900@livinglogic.de> <1055853119.3599.2.camel@anthem> <006901c334d4$63f7c840$125ffea9@oemcomputer> <20030617135722.GL12316@epoch.metaslash.com> <3EEF2509.4080208@livinglogic.de>
Message-ID: <3EEF2795.8000701@livinglogic.de>

Walter Dörwald wrote:

> Neal Norwitz wrote:
> 
>> Moving to python-dev.
>>
>> [...]
>> While overall I think the idea is worthwhile, I have two concerns:
>>  * the doc wasn't updated
>>  * negative indices are handled differently:
>>
>>         >>> 'abc'.split().index('a', -3)
>>         Traceback (most recent call last):
>>           File "<stdin>", line 1, in ?
>>         ValueError: list.index(x): x not in list
>>         >>> 'abc'.index('a', -3)
>>         0
>>
>> Neal
> 
> I'm working on a fix for this.

Guido was faster! ;)

The documentation doesn't have to be fixed, because it states
that index() works like find(), which it does now.

Bye,
    Walter Dörwald




From guido@python.org  Tue Jun 17 15:44:47 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 17 Jun 2003 10:44:47 -0400
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Objectslistobject.c,2.153,2.154
In-Reply-To: Your message of "Tue, 17 Jun 2003 09:57:22 EDT."
 <20030617135722.GL12316@epoch.metaslash.com>
References: <E19S8fH-0007zx-00@sc8-pr-cvs1.sourceforge.net> <3EEF0907.6040900@livinglogic.de> <1055853119.3599.2.camel@anthem> <006901c334d4$63f7c840$125ffea9@oemcomputer>
 <20030617135722.GL12316@epoch.metaslash.com>
Message-ID: <200306171444.h5HEilT12024@odiug.zope.com>

> While overall I think the idea is worthwhile, I have two concerns:
>  * the doc wasn't updated

Beta 2 hasn't been released yet; Raymond still has time to fix this.

>  * negative indices are handled differently:
> 
>         >>> 'abc'.split().index('a', -3)
>         Traceback (most recent call last):
>           File "<stdin>", line 1, in ?
>         ValueError: list.index(x): x not in list
>         >>> 'abc'.index('a', -3)
>         0

Do a CVS up and try again. ;-)

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


From jim@interet.com  Tue Jun 17 17:17:35 2003
From: jim@interet.com (James C. Ahlstrom)
Date: Tue, 17 Jun 2003 12:17:35 -0400
Subject: [Python-Dev] zipfile.py (SF #755031)
References: <20030615212655.GA3575@cthulhu.gerg.ca>
Message-ID: <002f01c334eb$f69b7d10$1fbc05c6@mpi9003>

> Hi Jim -- are you still the prime suspect for zipfile.py?  If so, could

The patch is #755987.  See also comments in bug 755031.

JimA


From misa@redhat.com  Tue Jun 17 17:26:30 2003
From: misa@redhat.com (Mihai Ibanescu)
Date: Tue, 17 Jun 2003 12:26:30 -0400 (EDT)
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <m3r85tspuk.fsf@mira.informatik.hu-berlin.de>
Message-ID: <Pine.LNX.4.44.0306171159230.1382-100000@coyote.devel.redhat.com>

On 16 Jun 2003, Martin v. [iso-8859-15] L=F6wis wrote:

> "Jeff Hobbs" <jeffh@ActiveState.com> writes:
>=20
> > Right, and Unicode 4.0 is fresh out of diapers.  You can't even get
> > the regular code charts yet, you have to view the 4.0 beta ones.  Wit=
h
> > 4.0 the non-BMP finally gets a notable amount of characters, but they
> > are fairly weird ones that I'd be surprised to find a public font for.
>=20
> Actually, Unicode 3.2 added most of them; Unicode 4.0 has only minor
> additions. The biggest addition is the CJK unified ideographs in plane
> 2, which is of significance to a fifth of the world population,
> potentially - these are all current characters (instead of being only
> of scientific interest).
>=20
> I agree that it will take a while to have fonts for these
> available. However, unavailability of fonts should not stop us from
> supporting such characters in the libraries. Characters must pass
> through many processing steps before being rendered, and all of these
> steps must work flawlessly. So I think it is a good thing to start
> today, to have the application software ready by the time fonts become
> available.

Hello,

Here are the reasons Red Hat went for ucs4:

- Red Hat 7.3 shipped python 2.2 (compiled in the python2 rpm). Not too=20
surprising that a number of configuration tools were already using it. Bu=
t=20
no one saw tkinter was broken until too late - yes it was compiled with=20
ucs4.

- Red Hat 8.0 went to --enable-unicode=3Ducs2:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D63965

- While shipping an erratum for 7.3 that updated python2 to 2.2.2, I=20
realized the compatibility mess we are in. 7.3 is UCS4, 8.0 is UCS2. Part=
=20
of the reasons Red Hat 9 is called 9 and not 8.1 is to suggest there are=20
things that are incompatible with previous versions. There should be a=20
note in the release notes, stating python is now UCS4. The logic I tried=20
to apply was exactly what Martin said earlier - I would prefer to break=20
compatibility now rather than later when more people would notice :-)=20
Arguably, we should have beaten the heck out of tkinter at Red Hat 8 time=
=20
and fix it then - almost 2 years ago, that is.

> > > When I tested it, I found that it would break very easily. I was us=
ing
> > > the Redhat procedure, though, so I might have made something wrong.
> >=20
> > Can you feed me some sample scripts offline to test with?
>=20
> Will do, but it may take some time. It was so obvious to me that this
> is not at all officially supported that I did not bother reporting it,
> or taking notes.

The patch for tcl that we came up with was, IIRC, posted somewhere on the=
=20
tcl sites. I'll have to dig to find it again.

So, I am willing to wear the brown paper bag for not letting the communit=
y=20
know about the UCS4 change well in advance. I find it surprising to find=20
out _now_ that _tkinter.c was the one that was broken, I wish I knew that=
=20
before poking at fixing tcl instead. I am surprised the tcl community was=
=20
not aware of this either.

Anyway, UCS4 is something I don't think we can change now - and after=20
reading Martin's post, it makes me feel it's the correct way to go. How=20
can we fix the tcl/python interaction? If you have suggestions, please le=
t=20
me know (off-list would be fine too).=20

Cheers,
Misa



From Steven Taschuk <staschuk@telusplanet.net>  Tue Jun 17 18:21:21 2003
From: Steven Taschuk <staschuk@telusplanet.net> (Steven Taschuk)
Date: Tue, 17 Jun 2003 11:21:21 -0600
Subject: [Python-Dev] Re: PEP-317
In-Reply-To: <20030611103103.C1157@tibia.amotlpaa.bogus>; from staschuk@telusplanet.net on Wed, Jun 11, 2003 at 10:31:03AM -0600
References: <1055330845.3ee7121d0c36c@mcherm.com> <200306111313.h5BDDTj20704@pcp02138704pcs.reston01.va.comcast.net> <20030611103103.C1157@tibia.amotlpaa.bogus>
Message-ID: <20030617112121.F716@tibia.amotlpaa.bogus>

Quoth I:
  [... PEP 317 rejected ...]
> I'll certainly add a section on the reasons, with discussion of
> the new-style exceptions question, and a summary of other feedback.

These additions have been made:
    <http://www.python.org/peps/pep-0317.html#rejection> (et seq.)
If anyone feels that the additions omit or inadequately treat
important points raised in the discussion, please let me know.
(By email, please; no reason to trouble py-dev with such.)

-- 
next-time-Gadget-<shakes fist>-ly yours, Steven Taschuk


From walter@livinglogic.de  Tue Jun 17 18:24:04 2003
From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Tue, 17 Jun 2003 19:24:04 +0200
Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Objectslistobject.c,2.153,2.154
In-Reply-To: <200306171637.h5HGbOk13052@odiug.zope.com>
References: <E19S8fH-0007zx-00@sc8-pr-cvs1.sourceforge.net> <3EEF0907.6040900@livinglogic.de> <1055853119.3599.2.camel@anthem> <006901c334d4$63f7c840$125ffea9@oemcomputer> <20030617135722.GL12316@epoch.metaslash.com> <3EEF2509.4080208@livinglogic.de> <200306171445.h5HEjR512039@odiug.zope.com>              <3EEF3C75.6010902@livinglogic.de> <200306171637.h5HGbOk13052@odiug.zope.com>
Message-ID: <3EEF4EB4.8010801@livinglogic.de>

Guido van Rossum wrote:

>>It's still not the same as for str:
>> >>> "123".index("3", 0L, sys.maxint+1)
>>2
>>[61232 refs]
>>*>>> list("123").index("3", 0L, sys.maxint+1)
>>Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>>OverflowError: long int too large to convert to int
> 
> Do you really care about such end cases?

At least str does.

Simply changing
    "ii", &i, &j
to
    "O&O&", _PyEval_SliceIndex, &i, _PyEval_SliceIndex, &j
in the PyArg_ParseTuple() call should fix it.

Bye,
    Walter Dörwald




From Raymond Hettinger" <python@rcn.com  Tue Jun 17 18:08:55 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Tue, 17 Jun 2003 13:08:55 -0400
Subject: [Python-Dev] Py2.3 Todo List
Message-ID: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>

Here is my todo list for Py2.3.
Feel free to comment on whether it is too late to pursue these
or whether I should continue to work on them for the second beta.

1) PEP 42 lists a request to add timeout settings to the higher level
    net libraries.   Should this still be done?  In Py2.3, sockets offers
    a setdefaulttimeout() function that provides an indirect way of
    meeting the same goal.

2) Jack Diedrich is working on two patches for itertools:
 
       itertools.window(iterable, n=2) --> (a0, a1), (a1, a2), (a2, a3), ...

       itertools.roundrobin(*iterables) which loops over the iterables 
       returning one element from each and then cycles back to the
       first until all of the iterables are exhausted:
           itertools.roundrobin('ab', 'cde') --> a, c, b, d, e

Both functions were discussed on comp.lang.python and have been
requested by multiple users.  Neither is easily implemented in terms
of the existing tools.  OTOH, the more tools you add, the harder it
is to comprehend the toolset as a whole.

3) difflib now has functions to create a context diff or unified diff.
A natural next step is to add a patch() function that applies the diff
and finishes the roundtrip.    It also helps fulfill the original reason for
adding the context/unified diffs which was to make it easier for
general python users to either create or apply patches.

4) I've had a long outstanding patch to add methods like isalpha() to
string objects.  The goal was to make sure that replacements exist
for all the tools in the string module.  The hold-up has been in
making UniCode equivalents.  If this is still wanted, I'll finish it up.


Raymond Hettinger






From guido@python.org  Tue Jun 17 18:31:53 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 17 Jun 2003 13:31:53 -0400
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: Your message of "Tue, 17 Jun 2003 13:08:55 EDT."
 <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
Message-ID: <200306171731.h5HHVrl13421@odiug.zope.com>

> Here is my todo list for Py2.3.
> Feel free to comment on whether it is too late to pursue these
> or whether I should continue to work on them for the second beta.
> 
> 1) PEP 42 lists a request to add timeout settings to the higher level
>     net libraries.   Should this still be done?  In Py2.3, sockets offers
>     a setdefaulttimeout() function that provides an indirect way of
>     meeting the same goal.

IMO this is API design that should be done without the time pressure
of a beta.  I'd like you to experiment a bit with the
setdefaulttimeout() approach to see if it is workable though.

> 2) Jack Diedrich is working on two patches for itertools:
>  
>        itertools.window(iterable, n=2) --> (a0, a1), (a1, a2), (a2, a3), ...
> 
>        itertools.roundrobin(*iterables) which loops over the iterables 
>        returning one element from each and then cycles back to the
>        first until all of the iterables are exhausted:
>            itertools.roundrobin('ab', 'cde') --> a, c, b, d, e
> 
> Both functions were discussed on comp.lang.python and have been
> requested by multiple users.  Neither is easily implemented in terms
> of the existing tools.  OTOH, the more tools you add, the harder it
> is to comprehend the toolset as a whole.

itertools is new and yours; if you're comfortable with this, I'm okay
with it.

> 3) difflib now has functions to create a context diff or unified diff.
> A natural next step is to add a patch() function that applies the diff
> and finishes the roundtrip.    It also helps fulfill the original reason for
> adding the context/unified diffs which was to make it easier for
> general python users to either create or apply patches.

Interesting.  My own need is not for patching but for a three-way
merge.  If you could add a direct API for that, it'd be great.
difflib.merge(mine, old, yours) -> new.  With conflict markers a la
diff3 -m -E.

> 4) I've had a long outstanding patch to add methods like isalpha() to
> string objects.  The goal was to make sure that replacements exist
> for all the tools in the string module.  The hold-up has been in
> making UniCode equivalents.  If this is still wanted, I'll finish it up.

I'm +0 on that.

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


From michel@dialnetwork.com  Tue Jun 17 20:36:20 2003
From: michel@dialnetwork.com (Michel Pelletier)
Date: Tue, 17 Jun 2003 14:36:20 -0500
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <4E301B33-A0A2-11D7-A0E8-0030655234CE@cwi.nl>
References: <4E301B33-A0A2-11D7-A0E8-0030655234CE@cwi.nl>
Message-ID: <200306171429.47386.michel@dialnetwork.com>

On Tuesday 17 June 2003 04:01, Jack Jansen wrote:
>  but there's one I'd like to elaborate a little on:
>
> Michel Pelletier said:
> > I belive the reverse, synchronize will reduce user error and
> > deadlocking code.  with explicit locks programmers will forget,=20
> > or become confused,
> > with when and how to explicitly lock and unlock.
>
> The problem is if one piece of code has
> =09synchronise a:
> =09=09...
> =09=09synchronise b:
> =09=09=09...
> and somewhere else you have
> =09synchronise b:
> =09=09...
> =09=09synchronise a:
> =09=09=09...

As you pointed out, the programmer must be aware of this when synchronizi=
ng=20
with any mechanism.  Would you prefer the manual say "don't do the above"=
 or=20
"don't do the below":

lock1 =3D thread.allocate_lock()
lock2 =3D thread.allocate_lock()

lock1.acquire()
try:
    lock2.acquire()
    try:
        ...
    finally:
        lock2.release()
finally:
    lock1.release()

# and somewhere else you have

lock2.acquire()
try:
    lock1.acquire()
    try:
        ...
    finally:
        lock1.release()
finally:
    lock2.release()

Maybe I did this wrong, but aren't the two (and Greg's "synchronized clas=
s")=20
all susceptible to this problem and it's not specificly a failure of the=20
'synchronize' keyword?

Thanks for your comments Jack, I'm going to add this to the discussion se=
ction=20
of the PEP.=20

-Michel


From guido@python.org  Tue Jun 17 20:43:53 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 17 Jun 2003 15:43:53 -0400
Subject: Kevin Jacobs: Re: [Python-Dev] Py2.3 Todo List
Message-ID: <200306171944.h5HJhrF13967@odiug.zope.com>

Anyone want to take this on?
------- Forwarded Message

Date:    Tue, 17 Jun 2003 15:18:07 -0400
From:    Kevin Jacobs <jacobs@penguin.theopalgroup.com>
To:      Guido van Rossum <guido@python.org>
Subject: Re: [Python-Dev] Py2.3 Todo List

I'll vote for applying patch #751916, which fixes some memory leaks in the
timeout code, and allows the SSL code to recover from keyboard interrupts.
I have several applications that work with 2.2.x that do not currently with
the 2.3 CVS due to this issue.

Thanks,
- -Kevin

- -- 
- --
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

------- End of Forwarded Message



From Jack.Jansen@cwi.nl  Tue Jun 17 21:04:04 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 17 Jun 2003 22:04:04 +0200
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <200306171429.47386.michel@dialnetwork.com>
Message-ID: <D894870C-A0FE-11D7-9796-000A27B19B96@cwi.nl>

On dinsdag, jun 17, 2003, at 21:36 Europe/Amsterdam, Michel Pelletier 
wrote:

> Maybe I did this wrong, but aren't the two (and Greg's "synchronized 
> class")
> all susceptible to this problem and it's not specificly a failure of 
> the
> 'synchronize' keyword?

Yes, all mechanisms are susceptible to the same problem, they're 
probably all three functionally equivalent (i.e. anything you can code 
with one you can code with the other).

The point I'm trying to make is that designing your locks is hard work 
especially if there are many locks. Let's for the sake of argument say 
that the amount of work to get things right is quadratic in the number 
of locks. This means that any language construct that invites people to 
create many locks will make it more difficult to get the code right.

I realise the argument I make sound pedantic (let's not make it too 
easy to do locking, so that only people who know what they're doing 
will use locking), but that's the way I actually do feel about the 
subject.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From martin@v.loewis.de  Tue Jun 17 21:53:38 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 17 Jun 2003 22:53:38 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <Pine.LNX.4.44.0306171159230.1382-100000@coyote.devel.redhat.com>
References: <Pine.LNX.4.44.0306171159230.1382-100000@coyote.devel.redhat.com>
Message-ID: <m3d6hc8lyl.fsf@mira.informatik.hu-berlin.de>

Mihai Ibanescu <misa@redhat.com> writes:

> Anyway, UCS4 is something I don't think we can change now - and after 
> reading Martin's post, it makes me feel it's the correct way to go. How 
> can we fix the tcl/python interaction? If you have suggestions, please let 
> me know (off-list would be fine too). 

For 2.3, I have fixed it in the way that you can build _tkinter in
both UCS-2 and UCS-4 against a UCS-2 Tcl, and you can build a UCS-4
Python against a UCS-4 Tcl.

What is missing is building a standard (i.e. UCS-2) Python against the
Redhat (i.e. UCS-4) Tcl. There is now a note in README telling people
to configure Python for UCS-4 on Redhat. It appears that all Redhat 9
users running into that so far find that acceptable.

Still, it would slightly simplify the build procedure to support UCS-2
Python against UCS-4 Tcl. To do that, that case needs to be detected
at compile time, and appropriate character-by-character conversions
must be made. This is not on my TODO list, but I would accept patches
that do that.

I have advised the Debian Python maintainer (Matthias Klose), that
staying with UCS-2 for Python 2.2 is a good idea, as there are still
problems left in 2.2. For 2.3, I have suggested that they build with
UCS-4, especially as one Debian package requires that. So for
compatibility across Linux distributions, I hope that distributors
will configure Python 2.3 with UCS-4 on Linux.

Regards,
Martin

P.S. What is IMO more urgently missing is "proper" support for that
feature in Tcl, if it is meant to be a feature, in terms of
documentation, configuration options, etc. Or, if Tcl maintainers
decide this is *not* a desirable feature, it would help if they say so
(but I think Jeff's comments indicate that this is unlikely).


From martin@v.loewis.de  Tue Jun 17 22:00:03 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 17 Jun 2003 23:00:03 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
Message-ID: <m38ys08lnw.fsf@mira.informatik.hu-berlin.de>

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

> 1) PEP 42 lists a request to add timeout settings to the higher level
>     net libraries.   Should this still be done?

No. It shouldn't be done wholesale, anyway, but with one protocol at a
time. Patches should get review, as this is tricky stuff.

> 2) Jack Diedrich is working on two patches for itertools:
>  
>        itertools.window(iterable, n=2) --> (a0, a1), (a1, a2), (a2, a3), ...
> 
>        itertools.roundrobin(*iterables) which loops over the iterables 
>        returning one element from each and then cycles back to the
>        first until all of the iterables are exhausted:
>            itertools.roundrobin('ab', 'cde') --> a, c, b, d, e

We are approaching *beta* *2*. No new features, please. I find it much
more important to get the release published than enhancing the features.

Anybody with spare times at his hands should look into the
ever-growing backlog of bug reports. Some of the bugs are really bad,
much worse than the features would do good.

For example, to do something really useful, get rid of the recursion
in SRE (although this might be beyond the scope of a beta 2 as well).

> 3) difflib now has functions to create a context diff or unified diff.
> A natural next step is to add a patch() function that applies the diff
> and finishes the roundtrip.

No additions.

> 4) I've had a long outstanding patch to add methods like isalpha() to
> string objects.  The goal was to make sure that replacements exist
> for all the tools in the string module.  The hold-up has been in
> making UniCode equivalents.  If this is still wanted, I'll finish it up.

It is still wanted, and I'd encourage you to come up with a
patch. However, getting that patch into 2.4 might still be early
enough, and you might have to start today to finish it before the
first beta of 2.4.

Regards,
Martin



From martin@v.loewis.de  Tue Jun 17 22:04:54 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 17 Jun 2003 23:04:54 +0200
Subject: Kevin Jacobs: Re: [Python-Dev] Py2.3 Todo List
In-Reply-To: <200306171944.h5HJhrF13967@odiug.zope.com>
References: <200306171944.h5HJhrF13967@odiug.zope.com>
Message-ID: <m34r2o8lft.fsf@mira.informatik.hu-berlin.de>

Guido van Rossum <guido@python.org> writes:

 > Anyone want to take this on?

Looks fine to me, but I won't apply it tonight.

Regards,
Martin


From barry@python.org  Tue Jun 17 22:07:21 2003
From: barry@python.org (Barry Warsaw)
Date: 17 Jun 2003 17:07:21 -0400
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9
 (post-SF#719880)
In-Reply-To: <m3d6hc8lyl.fsf@mira.informatik.hu-berlin.de>
References: <Pine.LNX.4.44.0306171159230.1382-100000@coyote.devel.redhat.com>
 <m3d6hc8lyl.fsf@mira.informatik.hu-berlin.de>
Message-ID: <1055884040.28022.19.camel@barry>

On Tue, 2003-06-17 at 16:53, Martin v. L=F6wis wrote:

> What is missing is building a standard (i.e. UCS-2) Python against the
> Redhat (i.e. UCS-4) Tcl. There is now a note in README telling people
> to configure Python for UCS-4 on Redhat. It appears that all Redhat 9
> users running into that so far find that acceptable.

It would be moderately nicer if configure could detect that UCS-4 was
required and automatically provide the --enable-unicode=3Ducs4 option.

-Barry




From greg@cosc.canterbury.ac.nz  Wed Jun 18 00:17:51 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed, 18 Jun 2003 11:17:51 +1200 (NZST)
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <4E301B33-A0A2-11D7-A0E8-0030655234CE@cwi.nl>
Message-ID: <200306172317.h5HNHpS08247@oma.cosc.canterbury.ac.nz>

> Note that this same problem turns up with Greg's "synchronised class"
> idea: if the language makes locking easy people will overuse it and it
> will come back to bite you

I don't think that should be used as a reason not to provide
higher-level facilities such as synchronised classes. It just
means we need to keep clearly in mind that they're not a
magical solution that enables people to write threaded code
without understanding the issues.

They will be tools for knowledgable users, not substitutes
for said knowledge, and they should be documented as such.

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


From jepler@unpythonic.net  Wed Jun 18 02:28:47 2003
From: jepler@unpythonic.net (Jeff Epler)
Date: Tue, 17 Jun 2003 20:28:47 -0500
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <1055884040.28022.19.camel@barry>
References: <Pine.LNX.4.44.0306171159230.1382-100000@coyote.devel.redhat.com> <m3d6hc8lyl.fsf@mira.informatik.hu-berlin.de> <1055884040.28022.19.camel@barry>
Message-ID: <20030618012844.GB8034@unpythonic.net>

On Tue, Jun 17, 2003 at 05:07:21PM -0400, Barry Warsaw wrote:
> On Tue, 2003-06-17 at 16:53, Martin v. L=F6wis wrote:
>=20
> > What is missing is building a standard (i.e. UCS-2) Python against th=
e
> > Redhat (i.e. UCS-4) Tcl. There is now a note in README telling people
> > to configure Python for UCS-4 on Redhat. It appears that all Redhat 9
> > users running into that so far find that acceptable.
>=20
> It would be moderately nicer if configure could detect that UCS-4 was
> required and automatically provide the --enable-unicode=3Ducs4 option.

You'd be insane to stuff this in just before releasing 2.3 (since this
is the first time I've ever written for autoconf), but here it is..

Running on a RedHat 9 machine:
checking for wchar.h... yes
checking for wchar_t... yes
checking size of wchar_t... 4
checking for UCS-4 tcl... yes
checking what type to use for unicode... wchar_t

Running on a RedHat 7.1 machine:
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for wchar_t... yes
checking size of wchar_t... 4
checking for UCS-4 tcl... no
checking what type to use for unicode... unsigned short

Tested nowhere else in the universe... in particular, there's no
attempt to find the location of the tcl.h header as setup.py does
since it's in /usr/include/tcl.h on my system.

Detection of UCS-4 tcl does not override the --enable-unicode=3D setting.
Someone who is building Python on a redhat9 system but does not want
_tkinter may want the chance to override it, if only due to increased
memory consumption of that build.

Jeff

--- Python-2.3b1/configure.in	2003-04-11 10:35:52.000000000 -0500
+++ local-Python-2.3b1/configure.in	2003-06-17 20:17:13.000000000 -0500
@@ -2400,6 +2400,18 @@
   AC_CHECK_SIZEOF(wchar_t, 4, [#include <wchar.h>])
 fi
=20
+AC_MSG_CHECKING(for UCS-4 tcl)
+have_ucs4_tcl=3Dno
+AC_TRY_COMPILE([
+#include <tcl.h>
+#if TCL_UTF_MAX !=3D 6
+# error "NOT UCS4_TCL"
+#endif], [], [
+  AC_DEFINE(HAVE_UCS4_TCL, 1, [Define this if you have tcl and TCL_UTF_M=
AX=3D=3D6])
+  have_ucs4_tcl=3Dyes
+])
+AC_MSG_RESULT($have_ucs4_tcl)
+
 AC_MSG_CHECKING(what type to use for unicode)
 dnl quadrigraphs "@<:@" and "@:>@" produce "[" and "]" in the output
 AC_ARG_ENABLE(unicode,=20
@@ -2410,7 +2422,12 @@
 if test $enable_unicode =3D yes
 then
-  # Without any arguments, Py_UNICODE defaults to two-byte mode
-  enable_unicode=3D"ucs2"
+  # Without any arguments, Py_UNICODE changes to match tcl (if present)
+  case "$have_ucs4_tcl" in
+  yes) enable_unicode=3D"ucs4"
+       ;;
+  *)   enable_unicode=3D"ucs2"
+       ;;
+  esac
 fi
=20
 AH_TEMPLATE(Py_UNICODE_SIZE,


From jeff@hobbs.org  Wed Jun 18 07:04:13 2003
From: jeff@hobbs.org (Jeff Hobbs)
Date: Tue, 17 Jun 2003 23:04:13 -0700
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <m3d6hc8lyl.fsf@mira.informatik.hu-berlin.de>
Message-ID: <AEEJJLFGECCKDONDOCKEMEMCGAAA.jeffh@activestate.com>

It was a busy day for me, but I wanted to address the open qs here:

> From: martin@v.loewis.de
> Mihai Ibanescu <misa@redhat.com> writes:
>
> > Anyway, UCS4 is something I don't think we can change now - and after
> > reading Martin's post, it makes me feel it's the correct way to go. How
> > can we fix the tcl/python interaction? If you have suggestions, please
let
> > me know (off-list would be fine too).

For Python perhaps, if there exist extensions which require it, but
I still didn't see any convincing argument to build Tcl UCS-4.  Since
Martin has corrected things to work with UCS-4 Python against UCS-2
Tcl, that seems like a more sane way to go.  I want to get a chance
to examine what connectivity issues he found, and look into the Tk
UCS-4 issues.  We know a lot more about UCS-2 Tcl (the standard).  It
also makes it compatible with RH8 Tcl and all the extensions that
people have already built.  That means extension rpms made on RH8
will work on RH9 (that is not currently the case).

I am interested in updating the build system to have a UCS-4 enabling
build switch, but the key thing that I am worried about is the very
notable excess memory usage by Tk when built with UCS-4 (just Tcl
seems to be fine).  Since there appears to be no imperative reason to
have a UCS-4 Tcl build (thanks to Martin's shimmy magic), it would
seem best not to have the default Tk bloating, along with the other
issues.

> P.S. What is IMO more urgently missing is "proper" support for that
> feature in Tcl, if it is meant to be a feature, in terms of
> documentation, configuration options, etc. Or, if Tcl maintainers
> decide this is *not* a desirable feature, it would help if they say so
> (but I think Jeff's comments indicate that this is unlikely).

Right, I'm aware of it, and will make it so for 8.4.4 and 8.5.  It
won't get back into 8.3 (which we consider end-of-devel life).
Which brings up another point ... since Martin, et al, also did a
great job correcting Tkinter support for 8.4, why not move up to
that as the base version (it is already the base version in SuSE
and Debian-testing)?  It is 100% upwards compatible from 8.3 and
provides numerous enhancements for Tk users (like compound buttons,
new core widgets, enhanced performance, etc).

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/



From Jack.Jansen@cwi.nl  Wed Jun 18 12:28:53 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 18 Jun 2003 13:28:53 +0200
Subject: [Python-Dev] New PEP: 319
In-Reply-To: <200306172317.h5HNHpS08247@oma.cosc.canterbury.ac.nz>
Message-ID: <0A5B85B8-A180-11D7-A0E8-0030655234CE@cwi.nl>

On Wednesday, Jun 18, 2003, at 01:17 Europe/Amsterdam, Greg Ewing wrote:

>> Note that this same problem turns up with Greg's "synchronised class"
>> idea: if the language makes locking easy people will overuse it and it
>> will come back to bite you
>
> I don't think that should be used as a reason not to provide
> higher-level facilities such as synchronised classes. It just
> means we need to keep clearly in mind that they're not a
> magical solution that enables people to write threaded code
> without understanding the issues.

I had a half-baked idea yesterday that I'd like to dump here. I haven't
thought it over, so it's probably bogus anyway, but still here goes:-)

The main deadlock problem is acquiring a second lock while you already 
hold
a lock. But completely disallowing this in the runtime system is overly 
restrictive.
So, what we need is knowledge about which locks we can acquire and which
ones we can't. In other words, if there is a statement
	synchronize lock:
		code
then while inside "code" you will not be allowed to do any more 
synchronize
statements. (I'm re-using the synchronize statement here, but the 
object is
really a lock, not a general object, and I'm not interested in syntax 
right now.
Also, this idea would work as well, or maybe even better, with Greg's 
synchronized
class scheme).
Whether an attempt to do so results in an error or warning I'm not sure.

If the author of the code has investigated interaction between "lock",
"otherlock" and "thirdlock" and believes the interaction is safe then 
you use the form
	synchronize lock allowing otherlock, thirdlock:
		code
and "code" will be allowed to synchronize on the other two locks.

This scheme puts the annotation at the outer lock, an alternative would 
be to
put it at the inner lock. That has its advantages too, because if you 
know your
code does not block nor acquire locks you can say something like
"synchronize lock allow_holding *". A third alternative would be to 
completely
decouple the annotation from the locking code, with a statement that
says "Locks lock, otherlock and thirdlock are mutually safe".
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman



From jeremy@zope.com  Wed Jun 18 17:11:06 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: 18 Jun 2003 12:11:06 -0400
Subject: [Python-Dev] Handler.setLevel()
Message-ID: <1055952666.16214.23.camel@slothrop.zope.com>

I think there's a bug in the logging package.

It defines a setLevel() method on Handler objects, but I can't find any
explanation of what it does.  I checked the code and calling setLevel()
sets an attribute that is never read.

I expected setLevel() to be a way to filter out messages below a certain
level.  Is that the intended effect?  If so, I'd be happy to fix it so
that it worked.

Jeremy




From jeremy@zope.com  Wed Jun 18 17:17:56 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: 18 Jun 2003 12:17:56 -0400
Subject: [Python-Dev] Handler.setLevel()
In-Reply-To: <1055952666.16214.23.camel@slothrop.zope.com>
References: <1055952666.16214.23.camel@slothrop.zope.com>
Message-ID: <1055953076.16210.25.camel@slothrop.zope.com>

On Wed, 2003-06-18 at 12:11, Jeremy Hylton wrote:
> I think there's a bug in the logging package.

Never mind.  I wasn't setting the level correctly.  After figuring out
how to set the level correctly, I figured out how it uses
getEffectiveLevel() to read the level attribute.

Jeremy




From martin@v.loewis.de  Wed Jun 18 21:13:57 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 18 Jun 2003 22:13:57 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <AEEJJLFGECCKDONDOCKEMEMCGAAA.jeffh@activestate.com>
References: <AEEJJLFGECCKDONDOCKEMEMCGAAA.jeffh@activestate.com>
Message-ID: <m34r2njg8q.fsf@mira.informatik.hu-berlin.de>

"Jeff Hobbs" <jeffh@ActiveState.com> writes:

> Right, I'm aware of it, and will make it so for 8.4.4 and 8.5.  It
> won't get back into 8.3 (which we consider end-of-devel life).
> Which brings up another point ... since Martin, et al, also did a
> great job correcting Tkinter support for 8.4, why not move up to
> that as the base version (it is already the base version in SuSE
> and Debian-testing)?  

If that helps: This is what Python 2.3 will do on Windows: ship with
Tcl 8.4.

> It is 100% upwards compatible from 8.3 and provides numerous
> enhancements for Tk users (like compound buttons, new core widgets,
> enhanced performance, etc).

Unfortunately, it is not. Tk decided to set some "indeterminate"
fields in event structures to '??', whereas earlier they have been
numbers. This has caused an incompatibility in Tkinter of Python 2.2.2
and earlier, which now crashes when trying to convert these to
integers. This has been fixed in Python 2.2.3 and 2.3, by not trying
to convert these fields, so that now Pmw crashes when interpreting
these fields as integers (where "crashes" means "raising Python
exceptions").

Regards,
Martin



From guido@python.org  Wed Jun 18 22:06:40 2003
From: guido@python.org (Guido van Rossum)
Date: Wed, 18 Jun 2003 17:06:40 -0400
Subject: [Python-Dev] Re: VC 7.1 compiler for key developers - last call!
In-Reply-To: Your message of "Fri, 13 Jun 2003 13:40:40 EDT."
Message-ID: <200306182106.h5IL6eP19406@odiug.zope.com>

OK, I've sent the VC compiler wishlist to Nick Hodapp Microsoft.
I received 18 requests, two of which came after I had sent in the
list (sorry, guys).  These folks will get their compiler:

Tim Peters
Guido van Rossum
Mark Hammond
Paul F. Dubois
Marc-Andre Lemburg
Martin v. Löwis
Gordon B McMillan
Robin Dunn
Todd Miller
Neal Norwitz

Nick said the order would be placed on July 1st to fall in the 2004
budget.  Delivery will take approximately 2 weeks from then.

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


From vinay_sajip@red-dove.com  Wed Jun 18 23:06:29 2003
From: vinay_sajip@red-dove.com (Vinay Sajip)
Date: Wed, 18 Jun 2003 23:06:29 +0100
Subject: [Python-Dev] Handler.setLevel()
References: <1055952666.16214.23.camel@slothrop.zope.com> <1055953076.16210.25.camel@slothrop.zope.com>
Message-ID: <001601c335e5$dfcf6600$652b6992@alpha>

> On Wed, 2003-06-18 at 12:11, Jeremy Hylton wrote:
> > I think there's a bug in the logging package.
>
> Never mind.  I wasn't setting the level correctly.  After figuring out
> how to set the level correctly, I figured out how it uses
> getEffectiveLevel() to read the level attribute.
>

OK. The handler level is checked in Logger.callHandlers(), whereas the
logger level is checked in calls such as Logger.info(), Logger.debug() etc.
The getEffectiveLevel() call returns a logger level - either one set in the
logger for which getEffectiveLevel() is called, or the nearest ancestor
logger which has a level set.

Vinay





From jeffh@ActiveState.com  Wed Jun 18 23:23:33 2003
From: jeffh@ActiveState.com (Jeff Hobbs)
Date: Wed, 18 Jun 2003 15:23:33 -0700
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <m34r2njg8q.fsf@mira.informatik.hu-berlin.de>
Message-ID: <PDEDIFMNJCFOKJPHIFJNMEKBDNAA.jeffh@activestate.com>

> From: martin@v.loewis.de
> > It is 100% upwards compatible from 8.3 and provides numerous
> > enhancements for Tk users (like compound buttons, new core widgets,
> > enhanced performance, etc).
>
> Unfortunately, it is not. Tk decided to set some "indeterminate"
> fields in event structures to '??', whereas earlier they have been
> numbers. This has caused an incompatibility in Tkinter of Python 2.2.2
> and earlier, which now crashes when trying to convert these to
> integers. This has been fixed in Python 2.2.3 and 2.3, by not trying
> to convert these fields, so that now Pmw crashes when interpreting
> these fields as integers (where "crashes" means "raising Python
> exceptions").

Ah yes, a few instances like that can be considered incompatible, but
it was really a correction for buggy behavior that existed in Tk.
You could make requests for event fields that were valid (depending
on the event type).  You either got lucky and got some random data,
or you could segfault.  This relates to these bugs:

https://sf.net/tracker/index.php?func=detail&aid=612110&group_id=12997&atid=
112997
https://sf.net/tracker/index.php?func=detail&aid=411307&group_id=12997&atid=
112997

Other items that are in this vein are different default sizes for
buttons on Windows (better native size), and more standard behavior
of transient toplevels across platforms (with docs).  You also get
stuff like the real XP scrollbar and auto-disabling of scrollbars
on Windows (native style).  Then there is of course the entirely new
native OS X Aqua support, but I'm not sure if Tkinter is ported for
OS X yet (??).

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/



From cnetzer@sonic.net  Thu Jun 19 02:54:04 2003
From: cnetzer@sonic.net (Chad Netzer)
Date: 18 Jun 2003 18:54:04 -0700
Subject: [Python-Dev] On the possibility of "optimizing" range() calls
 in for-loops
In-Reply-To: <00d401c333bb$b2519da0$125ffea9@oemcomputer>
References: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>
 <00d401c333bb$b2519da0$125ffea9@oemcomputer>
Message-ID: <1055987644.12242.50.camel@adsl-209.204.179.133.sonic.net>

On Sun, 2003-06-15 at 20:59, Raymond Hettinger wrote:

> The SF patch manager has a workable implementation of your idea:
> 
>     www.python.org/sf/738094  for i in range(N) optimization 
> 
> 
> The jury is still out on whether it is an elegant, brilliant patch or
> a horrendous hack.

Thanks for pointing out this patch to me.  It was a bit of a revelation,
since I had been looking at this issue from more of a byte code
generation and special casing standpoint, whereas this approach peeks
ahead right inside the range() builtin C implementation.  That makes it
quite straightforward, doesn't change the bytecode generation at all,
and nicely gets around all the issues I brought up in my original post
(ie. overriding the range() builtin, and handling python 2.3 PyLong
valued ranges (by not optimizing in those cases)).

Of course, I can see why it might cause some people to cringe, just
because it is snooping ahead in the frame.  But, it doesn't seem that
the value of 3 is likely to change often, so it probably won't add much
of a maintainance burden.

Hopefully this patch can be discussed further once 2.4 starts to be
talked about.  I think I'll try to gather some statistics on how often
this optimization would be employed in existing code bases, and thus,
how much of a speed/memory gain it is likely to give on average.  My
intuition is that the small overhead it introduces will be more than
made up for by the speed and memory use improvements it can bring.

-- 
Chad Netzer <cnetzer at sonic dot net>



From martin@v.loewis.de  Thu Jun 19 08:51:01 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 19 Jun 2003 09:51:01 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <PDEDIFMNJCFOKJPHIFJNMEKBDNAA.jeffh@activestate.com>
References: <PDEDIFMNJCFOKJPHIFJNMEKBDNAA.jeffh@activestate.com>
Message-ID: <m38yrybj4q.fsf@mira.informatik.hu-berlin.de>

"Jeff Hobbs" <jeffh@ActiveState.com> writes:

> Ah yes, a few instances like that can be considered incompatible, but
> it was really a correction for buggy behavior that existed in Tk.

Unfortunately, for Python, this was more than just a few instances. If
Tkinter receives an event, it would convert all fields wholesale,
regardless of whether they would be needed or not. That means that any
Tkinter application using Tk bind would crash - even if it did not
look at the event at all. There were ten or so bug reports about it,
both on SF and comp.lang.python.

Now, I understand the reason for the change, and I agree it is a
sensible change. It also is a serious incompatibility. I have no
problems with serious incompatibilities as long as they are properly
documented and announced.

Regards,
Martin


From guido@python.org  Thu Jun 19 13:19:46 2003
From: guido@python.org (Guido van Rossum)
Date: Thu, 19 Jun 2003 08:19:46 -0400
Subject: [Python-Dev] On the possibility of "optimizing" range() calls in
 for-loops
In-Reply-To: "Your message of 18 Jun 2003 18:54:04 PDT."
 <1055987644.12242.50.camel@adsl-209.204.179.133.sonic.net>
References: <1055563742.8007.9.camel@adsl-209.204.179.133.sonic.net>
 <00d401c333bb$b2519da0$125ffea9@oemcomputer>
 <1055987644.12242.50.camel@adsl-209.204.179.133.sonic.net>
Message-ID: <200306191219.h5JCJka28743@pcp02138704pcs.reston01.va.comcast.net>

> >     www.python.org/sf/738094  for i in range(N) optimization 
> > 
> > The jury is still out on whether it is an elegant, brilliant patch or
> > a horrendous hack.

Isn't this flawed in the case where it's called by a C function rather
than directly from the bytecode VM?  If the C function was called in
the spot marked X below:

    for ... in X(...): ...

(where X is the C function that calls range(), probably through some
PyObject_Call() variation), then the check in the patch would trigger
incorrectly.

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



From jepler@unpythonic.net  Thu Jun 19 14:07:42 2003
From: jepler@unpythonic.net (Jeff Epler)
Date: Thu, 19 Jun 2003 08:07:42 -0500
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <m38yrybj4q.fsf@mira.informatik.hu-berlin.de>
References: <PDEDIFMNJCFOKJPHIFJNMEKBDNAA.jeffh@activestate.com> <m38yrybj4q.fsf@mira.informatik.hu-berlin.de>
Message-ID: <20030619130738.GF18507@unpythonic.net>

On Thu, Jun 19, 2003 at 09:51:01AM +0200, Martin v. L=F6wis wrote:
> Now, I understand the reason for the change, and I agree it is a
> sensible change. It also is a serious incompatibility. I have no
> problems with serious incompatibilities as long as they are properly
> documented and announced.

The bind(n) manpage shipped with tcl 8.2.1 says this:
    Unless otherwise indicated, the replacement string  is the decimal
    value of the given field from the current event.  Some of the
    substitutions are only valid for certain types of  events; if
    they  are  used  for other types of events the value substituted
    is undefined.
If I was being a language-lawyer, I'd sure attempt to argue that "the
value substituted is undefined" means that "??" is one undefined value
permissible by the spec.

... but I can't seriously believe that, because the *type* of the field
is an integer, so to meet the letter of the manpage the undefined value=20
must be some integer (or string representing an integer), not a
non-integer string like "??".

Anyway, while I don't know the tcl/tk development process, I suspect
that if a Python advocate was active there (for instance, compiling
python against tcl/tk CVS and reporting breakage) that this might have
been avoided.  It's a pity that nobody has appointed themselves to this
role.  Even if the tk developers had still made the incompatible change
in a dot-dot-release (rather than, say, substituting a plainly
out-of-range integer, like -sys.maxint-1), the Python community would
have heard about it before that release was out of CVS.  It would be
nice if there was someone up ahead to make sure the light is not an
oncoming train.

I wish *I* had the time to do this but hell -- I can't get my company's
product to move forward from the 8.2.1 release whose manpage I quoted,
not even to a later 8.2.x release!

Jeff


From niemeyer@conectiva.com  Thu Jun 19 15:26:57 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Thu, 19 Jun 2003 11:26:57 -0300
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <m38ys08lnw.fsf@mira.informatik.hu-berlin.de>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer> <m38ys08lnw.fsf@mira.informatik.hu-berlin.de>
Message-ID: <20030619142657.GA16740@ibook>

> For example, to do something really useful, get rid of the recursion
> in SRE (although this might be beyond the scope of a beta 2 as well).

I've just done so! The recursion limit is gone. And the interesting
part is, there's less code, and the logic is a lot simpler and
more obvious. My tests have shown that there was no slow down, and
indeed some cases are faster. All regression tests succeed (besides
those that checked the recursion limit), and, of course, these work:

  >>> import re
  >>> re.match("^(?:x)*$", 5000000*"x")
  <_sre.SRE_Match object at 0x300eb258>
  >>> re.match("^(?:x)*?$", 5000000*"x")
  <_sre.SRE_Match object at 0x300eb5c8>

Now, for the question...

<jumping frenetically> Can I commit!? Can I commit!? </>

:-)

-- 
Gustavo Niemeyer
http://niemeyer.net


From skip@pobox.com  Thu Jun 19 16:56:08 2003
From: skip@pobox.com (Skip Montanaro)
Date: Thu, 19 Jun 2003 10:56:08 -0500
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030619142657.GA16740@ibook>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <m38ys08lnw.fsf@mira.informatik.hu-berlin.de>
 <20030619142657.GA16740@ibook>
Message-ID: <16113.56600.566479.958738@montanaro.dyndns.org>

    >> For example, to do something really useful, get rid of the recursion
    >> in SRE (although this might be beyond the scope of a beta 2 as well).

    Gustavo> I've just done so! The recursion limit is gone. 

Way to go, Gustavo!  I suspect we all owe you a beer (hic!). ;-)

    Gustavo> Now, for the question...

    Gustavo> <jumping frenetically> Can I commit!? Can I commit!? </>

If we weren't already at b1 I'd say go for it.  With the expectation of only
one more beta though, I'm not sure.  I'd like to see a third beta or
something else which would insure it gets plenty of testing.

Perhaps you could build a test coverage version of the interpreter using
gcc, run just the re regression tests and see if there are some lines of the
changed code which are not being properly exercised.  That would suggest
where more tests are warranted.

Skip



From nas@python.ca  Thu Jun 19 17:06:42 2003
From: nas@python.ca (Neil Schemenauer)
Date: Thu, 19 Jun 2003 09:06:42 -0700
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030619142657.GA16740@ibook>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer> <m38ys08lnw.fsf@mira.informatik.hu-berlin.de> <20030619142657.GA16740@ibook>
Message-ID: <20030619160642.GA17527@glacier.arctrix.com>

Gustavo Niemeyer wrote:
> <jumping frenetically> Can I commit!? Can I commit!? </>

It would be good if your fix was reviewed.  Can you post it on SF?

  Neil


From martin@v.loewis.de  Thu Jun 19 21:06:56 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 19 Jun 2003 22:06:56 +0200
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <20030619130738.GF18507@unpythonic.net>
References: <PDEDIFMNJCFOKJPHIFJNMEKBDNAA.jeffh@activestate.com>
 <m38yrybj4q.fsf@mira.informatik.hu-berlin.de>
 <20030619130738.GF18507@unpythonic.net>
Message-ID: <m3llvx4ysf.fsf@mira.informatik.hu-berlin.de>

Jeff Epler <jepler@unpythonic.net> writes:

> It would be nice if there was someone up ahead to make sure the
> light is not an oncoming train.

I first learned about the problem when a Debian bug report was
forwarded to Python, along with a patch. I can't recall whether this
was before or after the 8.4.2 release - notice that the incompatible
change was in a subminor release.

At that time I thought: well, the patch fixes the problem, so let's
just apply it and, life goes on. The Tk changelog entry reads

2003-02-28  Donal K. Fellows  <fellowsd@cs.man.ac.uk>

	* tests/bind.test (bind-16.44): 
	* generic/tkBind.c (ExpandPercents): Only allow events to see
	those expansions that are actually valid for them, and force the
	substitution of the rest as "??".  This stops some crashes on
	Windows and gets rid of bogus values everywhere.  [Bug #612110]

which made it quite clear that Tk people would not revert that change,
no matter what.

Regards,
Martin



From ais_rajesh@yahoo.com  Thu Jun 19 23:14:56 2003
From: ais_rajesh@yahoo.com (Rajesh Sudarsan)
Date: Thu, 19 Jun 2003 15:14:56 -0700 (PDT)
Subject: [Python-Dev] Python Mega Widgets doubt
Message-ID: <20030619221456.41568.qmail@web41606.mail.yahoo.com>

--0-1845458225-1056060896=:40256
Content-Type: text/plain; charset=us-ascii

Hi,
I am using PMW for creating a GUI. The input is given through XML file. A class parses through the XML file and creates the GUI using the PMW. The GUI consists of EntryWidgets and combo boxes. This is carried out at loading time. Now at runtime, when I change the value of these Entry Fields , how do I read these values? There are multiple XML files and hence multiple windows are created ..
Please help..
Regards,
Rajesh


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
--0-1845458225-1056060896=:40256
Content-Type: text/html; charset=us-ascii

<DIV>Hi,<BR>I am using PMW for creating a GUI. The input is given through XML file. A class parses through the XML file and creates the GUI using the PMW. The GUI consists of EntryWidgets and combo boxes. This is carried out at loading time. Now at runtime, when I change the value of these Entry Fields , how do I read these values? There are multiple XML files and hence multiple windows are created ..</DIV>
<DIV>Please help..</DIV>
<DIV>Regards,<BR>Rajesh</DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://pa.yahoo.com/*http://rd.yahoo.com/evt=1207/*http://promo.yahoo.com/sbc/">SBC Yahoo! DSL</a> - Now only $29.95 per month!
--0-1845458225-1056060896=:40256--


From aahz@pythoncraft.com  Thu Jun 19 23:24:42 2003
From: aahz@pythoncraft.com (Aahz)
Date: Thu, 19 Jun 2003 18:24:42 -0400
Subject: [Python-Dev] Python Mega Widgets doubt
In-Reply-To: <20030619221456.41568.qmail@web41606.mail.yahoo.com>
References: <20030619221456.41568.qmail@web41606.mail.yahoo.com>
Message-ID: <20030619222442.GA22593@panix.com>

On Thu, Jun 19, 2003, Rajesh Sudarsan wrote:
>
> I am using PMW for creating a GUI. The input is given through XML
> file. A class parses through the XML file and creates the GUI using
> the PMW. The GUI consists of EntryWidgets and combo boxes. This is
> carried out at loading time. Now at runtime, when I change the value
> of these Entry Fields , how do I read these values? There are multiple
> XML files and hence multiple windows are created ..
>
> Please help..

Sorry, python-dev is the wrong place to get help for this; python-dev is
for the people working on the Python project.  You'll get better
response from comp.lang.python (you can also get it as a mailing list
through http://mail.python.org/mailman/listinfo/python-list).
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra


From niemeyer@conectiva.com  Fri Jun 20 01:31:43 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Thu, 19 Jun 2003 21:31:43 -0300
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <16113.56600.566479.958738@montanaro.dyndns.org>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer> <m38ys08lnw.fsf@mira.informatik.hu-berlin.de> <20030619142657.GA16740@ibook> <16113.56600.566479.958738@montanaro.dyndns.org>
Message-ID: <20030620003142.GA21184@ibook>

> Way to go, Gustavo!  I suspect we all owe you a beer (hic!). ;-)

Thank you!! I'll mention this in the next time we meet. 8-)~

> If we weren't already at b1 I'd say go for it.  With the expectation
> of only one more beta though, I'm not sure.  I'd like to see a third
> beta or something else which would insure it gets plenty of testing.

Yes, another beta would be nice. Anyway, I'm open to whatever
the BDFL, or the BDFLT(eam) decides. :-)

> Perhaps you could build a test coverage version of the interpreter
> using gcc, run just the re regression tests and see if there are some
> lines of the changed code which are not being properly exercised.
> That would suggest where more tests are warranted.

Thanks for the suggestion! I've just done that, and commited the new
version to CVS. I was able to get 82% of coverage observating gcov's
output:

  82.07% of 1372 source lines executed in file ./Modules/_sre.c

This observation made me notice some interesting facts as well, like a
few unreachable places, not being used by the current parser/compiler.
This can probably be removed in the future.

Another thing I got in the process is the following regexp:

  re.match("(?=a)*", "a")

This will blow up the recursion limit in the current implementation,
and will consume all memory in the new implementation. IMO, this
should raise an error during the parsing process, as it makes no
sense to repeat a non-consuming group.

-- 
Gustavo Niemeyer
http://niemeyer.net


From niemeyer@conectiva.com  Fri Jun 20 01:40:00 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Thu, 19 Jun 2003 21:40:00 -0300
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030619160642.GA17527@glacier.arctrix.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer> <m38ys08lnw.fsf@mira.informatik.hu-berlin.de> <20030619142657.GA16740@ibook> <20030619160642.GA17527@glacier.arctrix.com>
Message-ID: <20030620004000.GB21184@ibook>

> > <jumping frenetically> Can I commit!? Can I commit!? </>
> 
> It would be good if your fix was reviewed.  Can you post it on SF?

Sure, once the code is completely ready. I'm still retouching the code.

Anyway, without any intention of pretending to be a smart ass, I don't
think someone will be able to test and review it anymore than I did.
I've been working on this code, and understanding how it works, for
quite some time now. If we do want this for 2.3, we should get this in
ASAP, since the best way to test it now is the real world. And, 
of course, revision control is always your friend. :-)

-- 
Gustavo Niemeyer
http://niemeyer.net


From niemeyer@conectiva.com  Fri Jun 20 02:42:32 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Thu, 19 Jun 2003 22:42:32 -0300
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030619142657.GA16740@ibook>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer> <m38ys08lnw.fsf@mira.informatik.hu-berlin.de> <20030619142657.GA16740@ibook>
Message-ID: <20030620014232.GA21842@ibook>

> <jumping frenetically> Can I commit!? Can I commit!? </>

FWIW, there's a preview version of the patch in SF #757624.

-- 
Gustavo Niemeyer
http://niemeyer.net


From drifty@alum.berkeley.edu  Fri Jun 20 02:51:41 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Thu, 19 Jun 2003 18:51:41 -0700
Subject: [Python-Dev] No Net at home
Message-ID: <3EF268AD.7060308@ocf.berkeley.edu>

Ah, the joys of a local Net outage.  No Net at home basically means I am 
cut off from the rest of the world.  Comcast gave me the usual "24 to 72 
hours" for when it will be over.

Regardless, I don't know when I will get to check mail again, so 
consider me out of commission for now.  The next Summary will be ready 
to be fact checked when I get Net back.

-Brett



From niemeyer@conectiva.com  Fri Jun 20 03:57:12 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Thu, 19 Jun 2003 23:57:12 -0300
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030620003142.GA21184@ibook>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer> <m38ys08lnw.fsf@mira.informatik.hu-berlin.de> <20030619142657.GA16740@ibook> <16113.56600.566479.958738@montanaro.dyndns.org> <20030620003142.GA21184@ibook>
Message-ID: <20030620025712.GA22299@ibook>

> Thanks for the suggestion! I've just done that, and commited the new
> version to CVS. I was able to get 82% of coverage observating gcov's
> output:
> 
>   82.07% of 1372 source lines executed in file ./Modules/_sre.c

FYI, I took some time to write an overview of the procedure
in my (wiki|web)log:

   https://moin.conectiva.com.br/GustavoNiemeyer

self-promoting-ly y'rs

-- 
Gustavo Niemeyer
http://niemeyer.net


From tim.one@comcast.net  Fri Jun 20 04:30:14 2003
From: tim.one@comcast.net (Tim Peters)
Date: Thu, 19 Jun 2003 23:30:14 -0400
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030619142657.GA16740@ibook>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEMEEKAB.tim.one@comcast.net>

[Gustavo Niemeyer]
> I've just done so! The recursion limit is gone. ...

Cool!  Very cool.  Check it in.  Note that the primary effect will be to
change complaints about the recursion limit to complaints about "infinite
loops in sre" <0.4 wink>.

BTW, it would be best to Fredrik Lundh's blessing for this, since sre is
still "his" package.  I'm copying him on this.  Some version of Gustavo's
patch is here:

    http://www.python.org/sf/757624



From niemeyer@conectiva.com  Fri Jun 20 05:19:05 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Fri, 20 Jun 2003 01:19:05 -0300
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <LNBBLJKPBEHFEDALKOLCKEMEEKAB.tim.one@comcast.net>
References: <20030619142657.GA16740@ibook> <LNBBLJKPBEHFEDALKOLCKEMEEKAB.tim.one@comcast.net>
Message-ID: <20030620041904.GA22382@ibook>

> > I've just done so! The recursion limit is gone. ...
> 
> Cool!  Very cool.  Check it in.  Note that the primary effect will be

Thanks! I'll do a few minor retouches, and check it in.

> to change complaints about the recursion limit to complaints about
> "infinite loops in sre" <0.4 wink>.

That's not true! They'll be about memory blowing up. ;-))

More seriously, the real infinite loops (like the one I've shown in the
other mail) should be prevented while parsing or compiling (which is
hopefully not hard), and the cases where the user matches against a
*really* huge string..  well..  1000**1000**1000 is easier. :-)

> BTW, it would be best to Fredrik Lundh's blessing for this, since sre is
> still "his" package.  I'm copying him on this.  Some version of Gustavo's
> patch is here:
> 
>     http://www.python.org/sf/757624

Given his wonderful work on SRE, I'd really like to know his opinion
about it. OTOH, I must confess I have a bad experience waiting for
Fredrik's opinion. :-) Hopefully, he will answer so quickly I'll feel
ashamed for even mentioning this.

-- 
Gustavo Niemeyer
http://niemeyer.net


From anthony@interlink.com.au  Fri Jun 20 07:56:12 2003
From: anthony@interlink.com.au (Anthony Baxter)
Date: Fri, 20 Jun 2003 16:56:12 +1000
Subject: [Python-Dev] SF CVS hosed?
Message-ID: <200306200656.h5K6uDvd011695@localhost.localdomain>

Attempting a cvs up at the moment is failing with:

cvs server: failed to create lock directory for `/cvsroot/python/python/dist/src' (/cvsroot/python/python/dist/src/#cvs.lock): Permission denied
cvs server: failed to obtain dir lock in repository `/cvsroot/python/python/dist/src'
cvs [server aborted]: read lock failed - giving up

... or is it just me?

Anthony


From Anthony Baxter <anthony@interlink.com.au>  Fri Jun 20 07:57:44 2003
From: Anthony Baxter <anthony@interlink.com.au> (Anthony Baxter)
Date: Fri, 20 Jun 2003 16:57:44 +1000
Subject: [Python-Dev] Re: SF CVS hosed?
Message-ID: <200306200657.h5K6virT011718@localhost.localdomain>

>>> Anthony Baxter wrote
> 
> Attempting a cvs up at the moment is failing with:
> 
> cvs server: failed to create lock directory for `/cvsroot/python/python/dist/
src' (/cvsroot/python/python/dist/src/#cvs.lock): Permission denied
> cvs server: failed to obtain dir lock in repository `/cvsroot/python/python/d
ist/src'
> cvs [server aborted]: read lock failed - giving up

After quite some time of not working, it of course started working 2 minutes 
after I sent this email. *sigh*

cvs: less bad than the alternatives...

Anthony


From Jack.Jansen@cwi.nl  Fri Jun 20 09:32:23 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 20 Jun 2003 10:32:23 +0200
Subject: [Python-Dev] Re: SF CVS hosed?
In-Reply-To: <200306200657.h5K6virT011718@localhost.localdomain>
Message-ID: <B722EABC-A2F9-11D7-B66E-0030655234CE@cwi.nl>

On Friday, Jun 20, 2003, at 08:57 Europe/Amsterdam, Anthony Baxter 
wrote:

>
>>>> Anthony Baxter wrote
>>
>> Attempting a cvs up at the moment is failing with:
>>
>> cvs server: failed to create lock directory for 
>> `/cvsroot/python/python/dist/
> src' (/cvsroot/python/python/dist/src/#cvs.lock): Permission denied
>> cvs server: failed to obtain dir lock in repository 
>> `/cvsroot/python/python/d
> ist/src'
>> cvs [server aborted]: read lock failed - giving up
>
> After quite some time of not working, it of course started working 2 
> minutes
> after I sent this email. *sigh*

It's still (or again?) failing for me...
Ah, it works again!

I'll assume its a transient problem for now. If it persists we should 
file a
support request later.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman



From fredrik@pythonware.com  Fri Jun 20 10:46:28 2003
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 20 Jun 2003 11:46:28 +0200
Subject: [Python-Dev] Py2.3 Todo List
References: <LNBBLJKPBEHFEDALKOLCKEMEEKAB.tim.one@comcast.net>
Message-ID: <032b01c33710$d6486920$ced241d5@hagrid>

tim wrote:

> BTW, it would be best to Fredrik Lundh's blessing for this, since sre is
> still "his" package.  I'm copying him on this.

on midsummer's eve?  I'm supposed to be eating pickled herring and
drinking schapps, not trying to decipher C code...

> Some version of Gustavo's patch is here:
> 
>     http://www.python.org/sf/757624

looking at the patch, I'm 95% confident that it's the right thing (or close
enough to the right thing ;-)

but reading the unified patch is not exactly trivial; a brief prose description
of the new mechanism would be nice.

have you benchmarked this on "real-world" examples, and on more than one
platform?  before-and-after figures for xmllib/tokenize on large source files
would be a good indication on the performance impact (if any).

(and to be slightly nitpicking, I think it's good style to keep the alphabetical
order when adding stuff to lists that are already in alphabetical order, unless
you have really good reasons no to...)

</F>


From walter@livinglogic.de  Fri Jun 20 11:24:02 2003
From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 20 Jun 2003 12:24:02 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030620025712.GA22299@ibook>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer> <m38ys08lnw.fsf@mira.informatik.hu-berlin.de> <20030619142657.GA16740@ibook> <16113.56600.566479.958738@montanaro.dyndns.org> <20030620003142.GA21184@ibook> <20030620025712.GA22299@ibook>
Message-ID: <3EF2E0C2.1000105@livinglogic.de>

Gustavo Niemeyer wrote:
>>Thanks for the suggestion! I've just done that, and commited the new
>>version to CVS. I was able to get 82% of coverage observating gcov's
>>output:
>>
>>  82.07% of 1372 source lines executed in file ./Modules/_sre.c
> 
> 
> FYI, I took some time to write an overview of the procedure
> in my (wiki|web)log:
> 
>    https://moin.conectiva.com.br/GustavoNiemeyer

Of course you can always patch the Makefile and add
"-fprofile-arcs -ftest-coverage" to the OPT variable. The best
solution would be to add a new configure option --with-coverage.

BTW, I'm currently working on a new coverage tool. The mayor
difference to Skip's tools is that the coverage information
is imported into a database, so coverage information can be
tracked over time.

Bye,
    Walter Dörwald



From andymac@bullseye.apana.org.au  Fri Jun 20 12:45:51 2003
From: andymac@bullseye.apana.org.au (Andrew MacIntyre)
Date: Fri, 20 Jun 2003 21:45:51 +1000 (EST)
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030620004000.GB21184@ibook>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <m38ys08lnw.fsf@mira.informatik.hu-berlin.de> <20030619142657.GA16740@ibook>
 <20030619160642.GA17527@glacier.arctrix.com> <20030620004000.GB21184@ibook>
Message-ID: <20030620214218.M36525@bullseye.apana.org.au>

On Thu, 19 Jun 2003, Gustavo Niemeyer wrote:

> > > <jumping frenetically> Can I commit!? Can I commit!? </>
> >
> > It would be good if your fix was reviewed.  Can you post it on SF?
>
> Sure, once the code is completely ready. I'm still retouching the code.
>
> Anyway, without any intention of pretending to be a smart ass, I don't
> think someone will be able to test and review it anymore than I did.
> I've been working on this code, and understanding how it works, for
> quite some time now. If we do want this for 2.3, we should get this in
> ASAP, since the best way to test it now is the real world. And,
> of course, revision control is always your friend. :-)

As I seem to have assumed responsibility for keeping Python buildable on
FreeBSD, which also seems to be the platform most sensitive to the
recursion issue, I'd very much like to test your patch!

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac@pcug.org.au             (alt) |        Belconnen  ACT  2616
Web:    http://www.andymac.org/               |        Australia


From blunck@gst.com  Fri Jun 20 15:22:52 2003
From: blunck@gst.com (Christopher Blunck)
Date: Fri, 20 Jun 2003 10:22:52 -0400
Subject: [Python-Dev] SF CVS hosed?
In-Reply-To: <200306200656.h5K6uDvd011695@localhost.localdomain>
References: <200306200656.h5K6uDvd011695@localhost.localdomain>
Message-ID: <20030620142252.GB28631@homer.gst.com>

Not sure if it's related but I've noticed cvs hiccups the past couple of
nights.  I'm anonymous (and thus not getting Permission denied) - but
thought I'd mention it in case its relevant.

I thought that somebody else had volunteered to host cvs on their company's
server(s) for a low cost.  

-c


On Fri, Jun 20, 2003 at 04:56:12PM +1000, Anthony Baxter wrote:
> 
> Attempting a cvs up at the moment is failing with:
> 
> cvs server: failed to create lock directory for `/cvsroot/python/python/dist/src' (/cvsroot/python/python/dist/src/#cvs.lock): Permission denied
> cvs server: failed to obtain dir lock in repository `/cvsroot/python/python/dist/src'
> cvs [server aborted]: read lock failed - giving up
> 
> ... or is it just me?
> 
> Anthony
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev

-- 
 10:20:00  up 34 days, 23:55, 10 users,  load average: 0.00, 0.04, 0.02


From niemeyer@conectiva.com  Fri Jun 20 15:49:27 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Fri, 20 Jun 2003 11:49:27 -0300
Subject: [Python-Dev] Re: SF CVS hosed?
In-Reply-To: <200306200657.h5K6virT011718@localhost.localdomain>
References: <200306200657.h5K6virT011718@localhost.localdomain>
Message-ID: <20030620144927.GB23141@ibook>

Hi Anthony!

> After quite some time of not working, it of course started working 2
> minutes after I sent this email. *sigh*
> 
> cvs: less bad than the alternatives...

Have you tried subversion? We've been using it here for some time now.
With this experience in mind, I'd say cvs is a lot worse than this
alternative. :-)

-- 
Gustavo Niemeyer
http://niemeyer.net


From niemeyer@conectiva.com  Fri Jun 20 16:16:54 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Fri, 20 Jun 2003 12:16:54 -0300
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <032b01c33710$d6486920$ced241d5@hagrid>
References: <LNBBLJKPBEHFEDALKOLCKEMEEKAB.tim.one@comcast.net> <032b01c33710$d6486920$ced241d5@hagrid>
Message-ID: <20030620151654.GC23141@ibook>

> on midsummer's eve?  I'm supposed to be eating pickled herring and
> drinking schapps, not trying to decipher C code...

I'm glad I was wrong.. :-)

> > Some version of Gustavo's patch is here:
> > 
> >     http://www.python.org/sf/757624
> 
> looking at the patch, I'm 95% confident that it's the right thing (or
> close enough to the right thing ;-)

Cool! :-)

> but reading the unified patch is not exactly trivial; a brief prose

Indeed. It looks awful. :-)

> description of the new mechanism would be nice.

Basically, MAX_REPEAT and MIN_REPEAT were changed from

<REPEAT> <skip> <min> <max> ... <(MAX|MIN)_UNTIL> ...

to

<(MAX|MIN)_REPEAT> <skip> <min> <max> ... <SUCCESS> ...

and all logic was moved from (MAX|MIN)_UNTIL to (MAX|MIN)_REPEAT.

In the implementation, the main change was turning mark_stack into a
generic data_stack, and using it to push the state of each iteration
from MAX_REPEAT, so that it can pop them out while backtracking.
Another way to implement this was to simply test tail-matching
forwards, but while this would save memory and be easier to implement,
it'd certainly affect performance.

MIN_REPEAT was quite straightforward, as it tests tail-matching
forwards, thus no state saving is necessary.

> have you benchmarked this on "real-world" examples, and on more than one
> platform?  before-and-after figures for xmllib/tokenize on large source files
> would be a good indication on the performance impact (if any).

No, I haven't done with real programs. OTOH, I've done tests with large
streams which explored the worse case of both algorithms, and it has
shown no negative impacts, and indeed it's faster in some situations.
For example, I could remove the MIN_REPEAT_ONE opcode, since the new
generic MIN_REPEAT implementation is as fast as the old specific
implementation. I'm also checking if it is possible to move some of the
intelligence in MAX_REPEAT_ONE to MAX_REPEAT.

Of course, I'll be thankful for any further benchmarks done on this
code.

> (and to be slightly nitpicking, I think it's good style to keep the
> alphabetical order when adding stuff to lists that are already in
> alphabetical order, unless you have really good reasons no to...)

I'm sorry. I thought it was ordered based on logic proximity, but I
should have looked more carefuly.

Thanks for reviewing it!

-- 
Gustavo Niemeyer
http://niemeyer.net


From Jack.Jansen@cwi.nl  Fri Jun 20 16:21:26 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 20 Jun 2003 17:21:26 +0200
Subject: [Python-Dev] SF CVS hosed?
In-Reply-To: <20030620142252.GB28631@homer.gst.com>
Message-ID: <DBD1C136-A332-11D7-B66E-0030655234CE@cwi.nl>

On Friday, Jun 20, 2003, at 16:22 Europe/Amsterdam, Christopher Blunck 
wrote:

> Not sure if it's related but I've noticed cvs hiccups the past couple 
> of
> nights.  I'm anonymous (and thus not getting Permission denied) - but
> thought I'd mention it in case its relevant.

You will have a different range of problems. Since a couple of days 
sourceforge
runs non-ssh CVS off the backup CVS server, so you see a picture that 
is 24 hours
old. I got bitten by this yesterday.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman



From kbk@shore.net  Fri Jun 20 17:44:38 2003
From: kbk@shore.net (Kurt B. Kaiser)
Date: Fri, 20 Jun 2003 12:44:38 -0400
Subject: [Python-Dev] SF CVS hosed?
In-Reply-To: <DBD1C136-A332-11D7-B66E-0030655234CE@cwi.nl> (Jack Jansen's
 message of "Fri, 20 Jun 2003 17:21:26 +0200")
References: <DBD1C136-A332-11D7-B66E-0030655234CE@cwi.nl>
Message-ID: <m3fzm4vgug.fsf@float.attbi.com>

Jack Jansen <Jack.Jansen@cwi.nl> writes:

> Since a couple of days sourceforge runs non-ssh CVS off the backup
> CVS server, so you see a picture that is 24 hours old. I got bitten
> by this yesterday.

Yes, on 13Jun I submitted a comment to the master bug they opened on
CVS performance.  They took both anonymous cvs and ViewCVS out of sync.

https://sourceforge.net/tracker/index.php?func=detail&aid=721915&group_id=1&atid=200001

My suggestion was to somehow provide current data to the developers on
a given project.

I have not as yet received a reply, though another comment was posted
by Moorman requesting no more comments (though the text of the original
bug requested comment :) because of the traffic generated by comments.

(So I sent a private email suggesting that SF consider sending the 
changes to a tracker item instead of the whole item every time someone
makes a comment.  I'm not holding my breath.)

Lately there have been a number of complaints that the anoncvs/ViewCVS is
as much as 3 days out of date, including one from Bruce Sherwood for
VPython.

In addition, the nightly tarballs are three days out of date, at least
on some projects, and they are getting many complaints on that.

The SF staff has taken to answering all comments and requests by posting
boilerplate.

Taken in with the general web site delays and errors, it does seem
like SF control over the situation is unraveling.

__
KBK


From kbk@shore.net  Fri Jun 20 17:57:10 2003
From: kbk@shore.net (Kurt B. Kaiser)
Date: Fri, 20 Jun 2003 12:57:10 -0400
Subject: [Python-Dev] SF CVS hosed?
In-Reply-To: <m3fzm4vgug.fsf@float.attbi.com> (kbk@shore.net's message of
 "Fri, 20 Jun 2003 12:44:38 -0400")
References: <DBD1C136-A332-11D7-B66E-0030655234CE@cwi.nl>
 <m3fzm4vgug.fsf@float.attbi.com>
Message-ID: <m3brwsvg9l.fsf@float.attbi.com>

Oh, and the download and CVS statistics have been completely
broken for many (possibly a majority) projects since 20May.

It seems some projects are getting assigned the traffic that
actually belongs to other projects.

IDLEfork, for example, shows only nine downloads of the new
beta (made 2 1/2 weeks ago) whereas the average for the previous
alpha was 17 per /day/, while other projects are complaining that
their download stats are way to /high/.
__
KBK


From mats@laplaza.org  Fri Jun 20 17:50:26 2003
From: mats@laplaza.org (Mats Wichmann)
Date: Fri, 20 Jun 2003 10:50:26 -0600
Subject: [Python-Dev] curses module has_key emulation
In-Reply-To: <20030620131852.19348.36746.Mailman@mail.python.org>
Message-ID: <5.1.0.14.1.20030620104146.02019108@mail.laplaza.org>

I've been heading down a twisted path that's
led me to run the curses regression test
on a build that's been forced to use the
curses has_key emulation code.

It fails on the "has_key(13)" line in the test,
and the has_key.py code looks questionable to me:
it does:

     capability_name = _capability_names[ch]

     if _curses.tigetstr(capability_name): return 1
     else: return 0


The keys in the _capability_names dictionary are
taken from the curses keycodes and are in the
range octal 0400 to 0777, so the dictionary lookup
on a key of 13 takes a KeyError exception - which
is not caught, as can be seen above.

Any thoughts?


  



From bokr@oz.net  Fri Jun 20 19:10:43 2003
From: bokr@oz.net (Bengt Richter)
Date: Fri, 20 Jun 2003 18:10:43 GMT
Subject: [Python-Dev] A vote against dict(keyword=value) sugar + musing on how to do it
Message-ID: <3ef339ee.100042203@news.oz.net>

I'd rather have unambiguous use of it for subclasses of dict.

    def md(**kw):return kw
    d = dict(md(keyword=value))

is not that much work. Unambiguous simple use in subclasses is more important IMO.

<musing>
If there were a way to partition arguments into multiple arg lists so __new__ could optionally
have separable lists for passing to base class constructors vs using for the
subclass __new__ vs letting __init__ maybe do something. E.g., you could separate multiple
lists with ';'

    class D(dict):
        def __new__(cls, *args, **kw; number=123,**subclass_kw):  #XXX# currently illegal
        self = dict.__new__(cls, *args, **kw)                     #XXX# shouldn't be legal unless
        self.color = subclass_kw.get('color','blue')              #     we can partition arg lists, IMO 
        self.number = number
        return self
    ...
    d1 = D(key=value, key2=value2)  #XXX# means default args for number, subclass_kw
    d2 = D(; 456, color='red')      #XXX# empty base dict, other non-default attributes

I.e., D is drop-in compatible for base-class-compatible construction calls, and has to be
different anyway for special subclass parameters, so the ';' seems ok. Or is there a hidden gotcha?

<tangential>
BTW, since a (name,value) tuple sequence also works, maybe it would be nice to be
able to construct such a sequence without quotes on the even-index elements. E.g., with
new keyword assoc:

    assoc(name0, val0, name1, val1, etc, etc) => [('name0',val0), ('name1',val1), ('etc', etc)]

This would provide the unquoted naming in an ordered context as well as the unordered keyword=value
pairings.

Or course, in source you can spell that
    zip('name0 name1 etc'.split(),
        [name0,name1,etc])
but that ugly for longer sequences where it's harder to match the pairs, not to mention
other considerations.
</tangential>
</musing>

Regards,
Bengt Richter
(copy to python-dev@python.org, per advice in c.l.p
"Subject: a clean way to define dictionary" thread.)

Regards,
Bengt Richter


From martin@v.loewis.de  Fri Jun 20 19:30:30 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 20 Jun 2003 20:30:30 +0200
Subject: [Python-Dev] Re: SF CVS hosed?
In-Reply-To: <20030620144927.GB23141@ibook>
References: <200306200657.h5K6virT011718@localhost.localdomain>
 <20030620144927.GB23141@ibook>
Message-ID: <m3he6kd2k9.fsf@mira.informatik.hu-berlin.de>

Gustavo Niemeyer <niemeyer@conectiva.com> writes:

> Have you tried subversion? We've been using it here for some time now.
> With this experience in mind, I'd say cvs is a lot worse than this
> alternative. :-)

I've been using svn also for some time now. While it definitely has
advantages, I also see a number of new problems: dav_svn is *much*
slower than cvs-over-ssh, and it is also less convenient, since there
is no real equivalent of ssh-agent for svn.

Regards,
Martin



From nas@python.ca  Fri Jun 20 20:19:49 2003
From: nas@python.ca (Neil Schemenauer)
Date: Fri, 20 Jun 2003 12:19:49 -0700
Subject: [Python-Dev] Re: SF CVS hosed?
In-Reply-To: <m3he6kd2k9.fsf@mira.informatik.hu-berlin.de>
References: <200306200657.h5K6virT011718@localhost.localdomain> <20030620144927.GB23141@ibook> <m3he6kd2k9.fsf@mira.informatik.hu-berlin.de>
Message-ID: <20030620191949.GA20513@glacier.arctrix.com>

Martin v. L?wis wrote:
> I've been using svn also for some time now. While it definitely has
> advantages, I also see a number of new problems: dav_svn is *much*
> slower than cvs-over-ssh,

We have been using Subversion for a few months now.  dav_svn is
painfully slow and we quickly moved to using svnserve+ssh.  It's not
quite as fast as CVS but tolerable.

> and it is also less convenient, since there
> is no real equivalent of ssh-agent for svn.

I take it you don't know about svnserve?

  Neil


From mats@laplaza.org  Fri Jun 20 20:32:29 2003
From: mats@laplaza.org (Mats Wichmann)
Date: Fri, 20 Jun 2003 13:32:29 -0600
Subject: [Python-Dev] Re: Python language standard; LSB
In-Reply-To: <20030613160005.859.34162.Mailman@mail.python.org>
Message-ID: <5.1.0.14.1.20030620131759.02017f80@mail.laplaza.org>

Tobias writes:

 >one thing that prevents the linux standard base to include Python (or Perl
 >for that matter) is that there is no formal language standard with test
 >cases. (For the LSB a subset might be enough.)
 >http://www.linuxbase.org/futures/faq.html#scope
 >
 >Exists there anywhere a rudimentary standard or are there plans to create
 >one?

well, stop paying attention for a bit (well, for months to
be honest) and see what happens.  As Tobias knows, working
on the LSB is my "day job", although he probably doesn't
know I hang out here, too.

The LSB standardization process has a number of steps in it;
one of the key ones is demand.  We're not really blocked
on a language standard or test suite, as has been pointed
out elsewhere, just picking a version and its' matching test
suite is close to good enough.  But what we don't have is
any really burning need to add more dynamic languages to
the LSB specification (a "posix shell" is included for
installation script purposes, so there is one).

What does it mean to be part of this standard?  It means
an application developer can count on specific functionality
to be present on a conforming system.  There are already
two answers for that:  you can bundle Python with your project,
Zope-style, or you can build your package to require an
lsb-conforming Python of a specific version to be installed
as a condition of installation (e.g., rpm dependency). The
LSB project already builds such a version of Python as
part of the "LSB application battery".  The LSB application
battery is used as a testbed of various functionality,
and part of that process is installing lsb-python and
running the Python regression test suite (in fact, it was
chosen - by me - for the existence of that test suite
which managed to beat on some things we don't have any
more formal tests for). Perl is not part of this at the
moment, by the way.

Plus, of course, most systems that are targets of this
already include Python, and a bit of care in coding ought
to make it possible to use the native version.

So until someone builds a "business case" that there's a
problem that can only be solved by trying to create a
"standard" for Python within the LSB, I don't see a lot of
reason for the LSB committee to worry about it...

Cheers,

Mats Wichmann



From martin@v.loewis.de  Fri Jun 20 20:36:41 2003
From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 20 Jun 2003 21:36:41 +0200
Subject: [Python-Dev] Re: SF CVS hosed?
In-Reply-To: <20030620191949.GA20513@glacier.arctrix.com>
References: <200306200657.h5K6virT011718@localhost.localdomain> <20030620144927.GB23141@ibook> <m3he6kd2k9.fsf@mira.informatik.hu-berlin.de> <20030620191949.GA20513@glacier.arctrix.com>
Message-ID: <3EF36249.6080508@v.loewis.de>

Neil Schemenauer wrote:
> We have been using Subversion for a few months now.  dav_svn is
> painfully slow and we quickly moved to using svnserve+ssh.  It's not
> quite as fast as CVS but tolerable.

That would require local users. On the machine that runs the repository,
this is not feasible, unfortunately (so CVS would be no option)

>>and it is also less convenient, since there
>>is no real equivalent of ssh-agent for svn.
> 
> 
> I take it you don't know about svnserve?

How does that help me in not having to type the password on
each commit?

I was shocked that svn would store the password typed *in the clear*,
and in some release even *in the sandbox*. Now it still stores it in
the home directory, which isn't much better... If you disable that,
you have to type the password every time. svn+ssh-agent would be a
solution, but, as I said, not in our case.

Regards,
Martin



From niemeyer@conectiva.com  Fri Jun 20 21:32:23 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Fri, 20 Jun 2003 17:32:23 -0300
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030620151654.GC23141@ibook>
References: <LNBBLJKPBEHFEDALKOLCKEMEEKAB.tim.one@comcast.net> <032b01c33710$d6486920$ced241d5@hagrid> <20030620151654.GC23141@ibook>
Message-ID: <20030620203223.GA30958@ibook>

> implementation. I'm also checking if it is possible to move some of
> the intelligence in MAX_REPEAT_ONE to MAX_REPEAT.

Good news and bad news. I was able to greatly improve some cases
using the priciples of MAX_REPEAT_ONE, but I also got a problem
in the current implementation. I'll be working on it.

-- 
Gustavo Niemeyer
http://niemeyer.net


From nas@python.ca  Fri Jun 20 23:35:03 2003
From: nas@python.ca (Neil Schemenauer)
Date: Fri, 20 Jun 2003 15:35:03 -0700
Subject: [Python-Dev] Re: SF CVS hosed?
In-Reply-To: <3EF36249.6080508@v.loewis.de>
References: <200306200657.h5K6virT011718@localhost.localdomain> <20030620144927.GB23141@ibook> <m3he6kd2k9.fsf@mira.informatik.hu-berlin.de> <20030620191949.GA20513@glacier.arctrix.com> <3EF36249.6080508@v.loewis.de>
Message-ID: <20030620223503.GA20868@glacier.arctrix.com>

"Martin v. L?wis" on svn+ssh:
> That would require local users. On the machine that runs the repository,
> this is not feasible, unfortunately (so CVS would be no option)

Previously you said:

     dav_svn is *much* slower than cvs-over-ssh, and it is also less
     convenient, since there is no real equivalent of ssh-agent for svn

My point is that if you use svn+ssh, it is much faster than dav_svn and
you can use ssh-agent.  Are you now saying you can't use cvs-over-ssh?
If so then I don't understand why you are talking about ssh-agent for
CVS.

In any case, this is all pretty off topic for python-dev so I'm going to
shutup now. :-)

  Neil


From mal@lemburg.com  Sat Jun 21 13:47:26 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Jun 2003 14:47:26 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
Message-ID: <3EF453DE.4040301@lemburg.com>

Raymond Hettinger wrote:
> Here is my todo list for Py2.3.
> 4) I've had a long outstanding patch to add methods like isalpha() to
> string objects.  The goal was to make sure that replacements exist
> for all the tools in the string module.  The hold-up has been in
> making UniCode equivalents.  If this is still wanted, I'll finish it up.

Hmm, Unicode object already have these methods...

I'd like to add another TODO to the list:

5) Add functions sys.setdefaultsourceencoding() and
    sys.getdefaultsourceencoding() which allow setting and
    querying the Python compiler's assumption about the
    default source code encoding (currently ASCII) much in
    the same way as sys.set/getdefaultencoding() work for
    the internal string encoding assumption.

    Just like the latter, sys.setdefaultsourceencoding() should
    only be usable in site.py and get deleted from the sys module
    in the same way after completed execution of site.py.

    I probably won't have time to write a patch for this, so
    volunteers are most welcome. If you have questions, feel free
    to ask.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 21 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                         3 days left



From martin@v.loewis.de  Sat Jun 21 14:01:06 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 21 Jun 2003 15:01:06 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <3EF453DE.4040301@lemburg.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <3EF453DE.4040301@lemburg.com>
Message-ID: <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>

"M.-A. Lemburg" <mal@lemburg.com> writes:

> > 4) I've had a long outstanding patch to add methods like isalpha() to
> > string objects.  The goal was to make sure that replacements exist
> > for all the tools in the string module.  The hold-up has been in
> > making UniCode equivalents.  If this is still wanted, I'll finish it up.
> 
> Hmm, Unicode object already have these methods...

I think Raymond is talking about methods *like* isalpha :-) See patch
562501, he wants ispunct, isgraph, isprint, isctrl, isxdigit, i.e. all
ctype.h macros. Unicode objects don't support these, and the ctype.h
macros aren't available for them.

> I'd like to add another TODO to the list:
> 
> 5) Add functions sys.setdefaultsourceencoding() and
>     sys.getdefaultsourceencoding() which allow setting and
>     querying the Python compiler's assumption about the
>     default source code encoding (currently ASCII) much in
>     the same way as sys.set/getdefaultencoding() work for
>     the internal string encoding assumption.

This should not go into 2.3 (just as the other features shouldn't go
there).

I personally envision that this is solved in a different way: Instead
of having a global setting, there should be a context-specific one,
for use in eval/exec, and interactive mode. The "default" encoding for
source code files should not be settable, and should remain at ASCII
forever.

Regards,
Martin


From ben@algroup.co.uk  Sat Jun 21 15:56:33 2003
From: ben@algroup.co.uk (Ben Laurie)
Date: Sat, 21 Jun 2003 15:56:33 +0100
Subject: [Python-Dev] SF CVS hosed?
In-Reply-To: <20030620142252.GB28631@homer.gst.com>
References: <200306200656.h5K6uDvd011695@localhost.localdomain> <20030620142252.GB28631@homer.gst.com>
Message-ID: <3EF47221.2070400@algroup.co.uk>

Christopher Blunck wrote:

> Not sure if it's related but I've noticed cvs hiccups the past couple of
> nights.  I'm anonymous (and thus not getting Permission denied) - but
> thought I'd mention it in case its relevant.
> 
> I thought that somebody else had volunteered to host cvs on their company's
> server(s) for a low cost.  

Me. But one thing I do need to know is how much bandwidth CVS uses,
which I haven't had an answer to yet.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



From mal@lemburg.com  Sat Jun 21 17:13:50 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Jun 2003 18:13:50 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>	<3EF453DE.4040301@lemburg.com> <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
Message-ID: <3EF4843E.60901@lemburg.com>

Martin v. L=F6wis wrote:
> "M.-A. Lemburg" <mal@lemburg.com> writes:
>=20
>=20
>>>4) I've had a long outstanding patch to add methods like isalpha() to
>>>string objects.  The goal was to make sure that replacements exist
>>>for all the tools in the string module.  The hold-up has been in
>>>making UniCode equivalents.  If this is still wanted, I'll finish it u=
p.
>>
>>Hmm, Unicode object already have these methods...
>=20
> I think Raymond is talking about methods *like* isalpha :-) See patch
> 562501, he wants ispunct, isgraph, isprint, isctrl, isxdigit, i.e. all
> ctype.h macros. Unicode objects don't support these, and the ctype.h
> macros aren't available for them.

I see.

>>I'd like to add another TODO to the list:
>>
>>5) Add functions sys.setdefaultsourceencoding() and
>>    sys.getdefaultsourceencoding() which allow setting and
>>    querying the Python compiler's assumption about the
>>    default source code encoding (currently ASCII) much in
>>    the same way as sys.set/getdefaultencoding() work for
>>    the internal string encoding assumption.
>=20
> This should not go into 2.3 (just as the other features shouldn't go
> there).

It was planned for 2.3 several months ago. The fact that
it isn't in there yet is mostly my fault: I didn't have time
to cook up a patch and forgot to ask here for other
volunteers.

> I personally envision that this is solved in a different way: Instead
> of having a global setting, there should be a context-specific one,
> for use in eval/exec, and interactive mode. The "default" encoding for
> source code files should not be settable, and should remain at ASCII
> forever.

This feature is needed to calm down concerns of non-ASCII
Python users who want to customize Python to better suit
their needs for both educational and production use
purposes.

The same disclaimers as for the sys.setdefaultencoding() pair
of APIs apply to these too.

The implementation should follow the same path that the
default encoding is using (storing it in the interpreter
state instead of a global).

--=20
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 21 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                         3 days left



From martin@v.loewis.de  Sat Jun 21 17:20:51 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 21 Jun 2003 18:20:51 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <3EF4843E.60901@lemburg.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <3EF453DE.4040301@lemburg.com>
 <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
 <3EF4843E.60901@lemburg.com>
Message-ID: <m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>

"M.-A. Lemburg" <mal@lemburg.com> writes:

> It was planned for 2.3 several months ago. The fact that
> it isn't in there yet is mostly my fault: I didn't have time
> to cook up a patch and forgot to ask here for other
> volunteers.

You mean, this was your plan? I am not aware of such a plan, and it is
not part of the approved PEP 263. I would strongly object to such a
change.

> This feature is needed to calm down concerns of non-ASCII
> Python users who want to customize Python to better suit
> their needs for both educational and production use
> purposes.

People who want such a feature will have to fork Python. However, most
users will accept to put encoding declarations into their source code.
They will curse, and then they will get over it.

Regards,
Martin


From mal@lemburg.com  Sat Jun 21 17:31:04 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sat, 21 Jun 2003 18:31:04 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>	<3EF453DE.4040301@lemburg.com>	<m38yrvoa99.fsf@mira.informatik.hu-berlin.de>	<3EF4843E.60901@lemburg.com> <m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>
Message-ID: <3EF48848.8040707@lemburg.com>

Martin v. L=F6wis wrote:
> "M.-A. Lemburg" <mal@lemburg.com> writes:
>=20
>>It was planned for 2.3 several months ago. The fact that
>>it isn't in there yet is mostly my fault: I didn't have time
>>to cook up a patch and forgot to ask here for other
>>volunteers.
>=20
> You mean, this was your plan?

Partly, yes. Guido and I decided to add this feature in private
discussions with Python users who were strongly opposed to
the PEP 263 way of forcing the ASCII encoding onto existing
Python source code.

> I am not aware of such a plan, and it is
> not part of the approved PEP 263. I would strongly object to such a
> change.

Why is that ? The proposed APIs will work just like their
counterparts for the internal Unicode/string conversion which
have proven to quiet down discussions about choosing ASCII
as default encoding. I expect the same to happen for the
Python source code encoding default.

>>This feature is needed to calm down concerns of non-ASCII
>>Python users who want to customize Python to better suit
>>their needs for both educational and production use
>>purposes.
>=20
> People who want such a feature will have to fork Python. However, most
> users will accept to put encoding declarations into their source code.
> They will curse, and then they will get over it.

No need to fork Python :-) They can customize their site.py
settings to their liking; of course, they will also have to live
with the consequences, just as the users who tweak the default
encoding of the interpreter.

"Practicality beats purity."

--=20
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 21 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                         3 days left



From martin@v.loewis.de  Sat Jun 21 20:11:33 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 21 Jun 2003 21:11:33 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <3EF48848.8040707@lemburg.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <3EF453DE.4040301@lemburg.com>
 <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
 <3EF4843E.60901@lemburg.com>
 <m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>
 <3EF48848.8040707@lemburg.com>
Message-ID: <m3n0gbjlei.fsf@mira.informatik.hu-berlin.de>

"M.-A. Lemburg" <mal@lemburg.com> writes:

> > I am not aware of such a plan, and it is
> > not part of the approved PEP 263. I would strongly object to such a
> > change.
> 
> Why is that ? The proposed APIs will work just like their
> counterparts for the internal Unicode/string conversion which
> have proven to quiet down discussions about choosing ASCII
> as default encoding.

But do they have done good? I don't consider quieting down of
discussions a good thing per se.

> "Practicality beats purity."

That is, unfortunately, convincing. I'll certainly bow to BDFL
pronouncement, but I don't have to like this feature.

So I withdraw my observation that this would be out of scope for the
next beta. I'll hope that nobody volunteers to implement it, anyway
:-) Any potential implementer, please find a way to integrate this
with IDLE: In absence of a declared source encoding, IDLE should then
probably assume that source files are in the system source encoding.

Regards,
Martin


From aahz@pythoncraft.com  Sat Jun 21 20:37:25 2003
From: aahz@pythoncraft.com (Aahz)
Date: Sat, 21 Jun 2003 15:37:25 -0400
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <3EF4843E.60901@lemburg.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer> <3EF453DE.4040301@lemburg.com> <m38yrvoa99.fsf@mira.informatik.hu-berlin.de> <3EF4843E.60901@lemburg.com>
Message-ID: <20030621193725.GA1335@panix.com>

On Sat, Jun 21, 2003, M.-A. Lemburg wrote:
> Martin v. L=F6wis wrote:
>>"M.-A. Lemburg" <mal@lemburg.com> writes:
>>>
>>>5) Add functions sys.setdefaultsourceencoding() and
>>>   sys.getdefaultsourceencoding() which allow setting and
>>>   querying the Python compiler's assumption about the
>>>   default source code encoding (currently ASCII) much in
>>>   the same way as sys.set/getdefaultencoding() work for
>>>   the internal string encoding assumption.
>>
>>This should not go into 2.3 (just as the other features shouldn't go
>>there).
>=20
> It was planned for 2.3 several months ago. The fact that it isn't in
> there yet is mostly my fault: I didn't have time to cook up a patch
> and forgot to ask here for other volunteers.

-1 unless Guido puts forth a Pronouncement that there will be two more
betas instead of just one.

-0 on a function that imports a specific module with a specific encoding.

While I understand the pain, I really don't want to break what "beta"
means.  I think that no patch should be accepted unless Guido explicitly
Pronounces that it's okay this late.
--=20
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.=
com/

Usenet is not a democracy.  It is a weird cross between an anarchy and a
dictatorship. =20


From mal@lemburg.com  Sat Jun 21 23:22:29 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Sun, 22 Jun 2003 00:22:29 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <m3n0gbjlei.fsf@mira.informatik.hu-berlin.de>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>	<3EF453DE.4040301@lemburg.com>	<m38yrvoa99.fsf@mira.informatik.hu-berlin.de>	<3EF4843E.60901@lemburg.com>	<m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>	<3EF48848.8040707@lemburg.com> <m3n0gbjlei.fsf@mira.informatik.hu-berlin.de>
Message-ID: <3EF4DAA5.90709@lemburg.com>

Martin v. L=F6wis wrote:
> "M.-A. Lemburg" <mal@lemburg.com> writes:
>=20
>=20
>>>I am not aware of such a plan, and it is
>>>not part of the approved PEP 263. I would strongly object to such a
>>>change.
>>
>>Why is that ? The proposed APIs will work just like their
>>counterparts for the internal Unicode/string conversion which
>>have proven to quiet down discussions about choosing ASCII
>>as default encoding.
>=20
> But do they have done good? I don't consider quieting down of
> discussions a good thing per se.

Providing more options often helps in finding compromises.
Not that I like any of these APIs or that I have ever
used them, but if they make people happy, I don't mind
exposing them.

>>"Practicality beats purity."
>=20
> That is, unfortunately, convincing. I'll certainly bow to BDFL
> pronouncement, but I don't have to like this feature.

No question about that :-)

> So I withdraw my observation that this would be out of scope for the
> next beta. I'll hope that nobody volunteers to implement it, anyway
> :-) Any potential implementer, please find a way to integrate this
> with IDLE: In absence of a declared source encoding, IDLE should then
> probably assume that source files are in the system source encoding.

I think that we can safely leave providing patches for this
to the people who will make use of the feature :-)

--=20
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 22 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                         2 days left



From jeffh@ActiveState.com  Sun Jun 22 01:39:26 2003
From: jeffh@ActiveState.com (Jeff Hobbs)
Date: Sat, 21 Jun 2003 17:39:26 -0700
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <m3llvx4ysf.fsf@mira.informatik.hu-berlin.de>
Message-ID: <PDEDIFMNJCFOKJPHIFJNKEOBDNAA.jeffh@activestate.com>

> From: martin@v.loewis.de
> I first learned about the problem when a Debian bug report was
> forwarded to Python, along with a patch. I can't recall whether this
> was before or after the 8.4.2 release - notice that the incompatible
> change was in a subminor release.

Well, it was a correction to a bug fix that could cause Tk to crash.
Crashing situations certainly merit placement in patchlevel releases.
I think JeffE was more hoping that ints would remain ints for those
fields with known types, ie use 0 instead of ??.  The problem is that
(IIRC) the type info was ignored for non-valid event data.

> At that time I thought: well, the patch fixes the problem, so let's
> just apply it and, life goes on. The Tk changelog entry reads
> 
> 2003-02-28  Donal K. Fellows  <fellowsd@cs.man.ac.uk>
> 
> 	* tests/bind.test (bind-16.44): 
> 	* generic/tkBind.c (ExpandPercents): Only allow events to see
> 	those expansions that are actually valid for them, and force the
> 	substitution of the rest as "??".  This stops some crashes on
> 	Windows and gets rid of bogus values everywhere.  [Bug #612110]
> 
> which made it quite clear that Tk people would not revert that change,
> no matter what.

When it comes to fixing bugs that can cause compat issues, we are
usually prett good about noting them in direct announcement release
notes.  Checking up, I see that this was noted appropriately in the
Tcl 8.4.2 release announcement (last item):

https://sourceforge.net/project/shownotes.php?release_id=144142

"""
  * Make %-substitutions for events only read data out of the event
    structure when that field is valid for that event type.
	*** POTENTIAL INCOMPATIBILITY ***
"""

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/



From jeffh@ActiveState.com  Sun Jun 22 01:50:34 2003
From: jeffh@ActiveState.com (Jeff Hobbs)
Date: Sat, 21 Jun 2003 17:50:34 -0700
Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880)
In-Reply-To: <20030619130738.GF18507@unpythonic.net>
Message-ID: <PDEDIFMNJCFOKJPHIFJNEEOCDNAA.jeffh@activestate.com>

> ... but I can't seriously believe that, because the *type* of the field
> is an integer, so to meet the letter of the manpage the undefined value 
> must be some integer (or string representing an integer), not a
> non-integer string like "??".

OK, looking in tk/generic/tkBind.c:ExpandPercents, I see that it would
be quite possible to correct this to use 0 or -1 for those fields that
want to be ints.  All the cases that are now correctly checking that
the field would be valid just need a final else clause that would give
some default int value (could even be event-field-specific).  I'm not
going to patch it, but I would accept it if someone wants to do that.

> Anyway, while I don't know the tcl/tk development process, I suspect
> that if a Python advocate was active there (for instance, compiling
> python against tcl/tk CVS and reporting breakage) that this might have
> been avoided.  It's a pity that nobody has appointed themselves to this

Anyone is welcome to join the process.  I'd even add someone as a tk
cvs member if they wished.  While I can (and do) check bug reports
for Tkinter that find their way to me, I don't have the bandwidth to
do more.

> I wish *I* had the time to do this but hell -- I can't get my company's
> product to move forward from the 8.2.1 release whose manpage I quoted,
> not even to a later 8.2.x release!

Well, that's *only* 4 years old. ;^)  I recently worked with a very
large company to upgrade some key systems that still had Tcl 7.1
embedded (we're talking 1995 code).  <shudder>

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/



From niemeyer@conectiva.com  Sun Jun 22 02:52:16 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Sat, 21 Jun 2003 22:52:16 -0300
Subject: [Python-Dev] More work on SRE
Message-ID: <20030622015216.GA11520@ibook>

There's a new version of the patch

    http://www.python.org/sf/757624

I understood there was some problems with the first implementation,
and changed some aspects of how the new implementation works to fix them.

This new implementation is more complex than the other implementations
(mine, and the original), given the many details it covers, but is
probably faster than these implementations in all situations (tests
very welcome). Additionally, it introduces new features like infinite
loop protection (*matching* the REs, not preventing their use).

Here is a list of valid REs not accepted by the original implementation,
and gracefully working on the new implementation (these used to blow up
SRE with an infinite loop, not because the implementation was recursive).

    re.match("(a?)+ab", "ab")
    re.match("^(a|b?)+a$", "a")
    re.match("(a*)+?ac", "ab")
    re.match("((a)*)+?ac", "ab")
    re.match("(?=a)*", "a")

Here is a list of unusual REs I've built while I was understanding how
complex the operations could be. All of them work.

    re.search('(.*?)(?<!-):', 'bc-:')
    re.match("(.+)+B", "AB")
    re.match("^(a+){2}b$", "aaaaab").groups()
    re.match("^(a+)+a$", "aaaaaa").groups()
    re.match("^((a|b?)a)+a$", "aa").groups()

The following RE is a good example of how *not to* build a regular
expression. The current implementation hangs for a *long* time
while executing it (more than many minutes.. I wasn't able to wait).
The new implementation takes as long as 2 seconds. Notice that
even the new implementation hangs (exponentially) with larger
strings.

    re.match("(a+?)+?ac", "a"*1000+"b")

The following SF issues were fixed, without being specifically
addressed (IOW, they just work :-):

    * 695688
    * 753711
    * 725149

As a matter of giving credits, I've included part of the lastmark
patch by Greg Chapman (712900).

Now, I understand that this is complex stuff, thus any kind of
help is very welcome. Here is how you can help:

    * provide benchmarks, good or bad, or provide
      "ready-to-benchmark" code;
    * provide information about tests you've done, good or bad,
      or provide "ready-to-test" code;

Also, I don't know about any bugs in the SRE engine which are not
fixed in the new implementation. If you have any non-working code
or some SF bug I'm not aware of, please let me know.

Ahhh.. now I'll relax a little bit. :-)

-- 
Gustavo Niemeyer
http://niemeyer.net



From niemeyer@conectiva.com  Sun Jun 22 02:56:58 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Sat, 21 Jun 2003 22:56:58 -0300
Subject: [Python-Dev] Re: Python language standard; LSB
In-Reply-To: <5.1.0.14.1.20030620131759.02017f80@mail.laplaza.org>
References: <20030613160005.859.34162.Mailman@mail.python.org> <5.1.0.14.1.20030620131759.02017f80@mail.laplaza.org>
Message-ID: <20030622015658.GB11520@ibook>

[... nice explanation ...]

> So until someone builds a "business case" that there's a
> problem that can only be solved by trying to create a
> "standard" for Python within the LSB, I don't see a lot of
> reason for the LSB committee to worry about it...

Thanks for the nice explanation. That's the most obvious way
I imagined things should work. Nice to know we're all on the
same ship. :-)

-- 
Gustavo Niemeyer
http://niemeyer.net


From guido@python.org  Sun Jun 22 08:43:32 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 22 Jun 2003 03:43:32 -0400
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: "Your message of Sat, 21 Jun 2003 15:37:25 EDT."
 <20030621193725.GA1335@panix.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <3EF453DE.4040301@lemburg.com> <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
 <3EF4843E.60901@lemburg.com> <20030621193725.GA1335@panix.com>
Message-ID: <200306220743.h5M7hWw03875@pcp02138704pcs.reston01.va.comcast.net>

> -1 unless Guido puts forth a Pronouncement that there will be two more
> betas instead of just one.

I'm pressed for time and we're late.  I'd rather get it out that do
another beta.  I think Martin might be able to take over deciding on
what can go into the next beta and what not.  There's always 2.3.1.

I'll discuss this with Martin at EuroPython in a few days.

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



From guido@python.org  Sun Jun 22 08:44:43 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 22 Jun 2003 03:44:43 -0400
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: "Your message of 21 Jun 2003 21:11:33 +0200."
 <m3n0gbjlei.fsf@mira.informatik.hu-berlin.de>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <3EF453DE.4040301@lemburg.com> <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
 <3EF4843E.60901@lemburg.com> <m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>
 <3EF48848.8040707@lemburg.com> <m3n0gbjlei.fsf@mira.informatik.hu-berlin.de>
Message-ID: <200306220744.h5M7ih203895@pcp02138704pcs.reston01.va.comcast.net>

> "M.-A. Lemburg" <mal@lemburg.com> writes:
> 
> > > I am not aware of such a plan, and it is
> > > not part of the approved PEP 263. I would strongly object to such a
> > > change.
> > 
> > Why is that ? The proposed APIs will work just like their
> > counterparts for the internal Unicode/string conversion which
> > have proven to quiet down discussions about choosing ASCII
> > as default encoding.

[MvL]
> But do they have done good? I don't consider quieting down of
> discussions a good thing per se.
> 
> > "Practicality beats purity."
> 
> That is, unfortunately, convincing. I'll certainly bow to BDFL
> pronouncement, but I don't have to like this feature.
> 
> So I withdraw my observation that this would be out of scope for the
> next beta. I'll hope that nobody volunteers to implement it, anyway
> :-) Any potential implementer, please find a way to integrate this
> with IDLE: In absence of a declared source encoding, IDLE should then
> probably assume that source files are in the system source encoding.

Let's discuss this at EuroPython.  We're all (MvL, MAL, me) going to
be there, right?

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


From guido@python.org  Sun Jun 22 08:48:24 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 22 Jun 2003 03:48:24 -0400
Subject: [Python-Dev] More work on SRE
In-Reply-To: "Your message of Sat, 21 Jun 2003 22:52:16 -0300."
 <20030622015216.GA11520@ibook>
References: <20030622015216.GA11520@ibook>
Message-ID: <200306220748.h5M7mOB03928@pcp02138704pcs.reston01.va.comcast.net>

> There's a new version of the patch
> 
>     http://www.python.org/sf/757624
> 
> I understood there was some problems with the first implementation,
> and changed some aspects of how the new implementation works to fix them.

BDFL Pronouncement: let's not add this to the 2.3 release.  We can add
it to CVS after 2.3 is out the door and it will be included in the 2.3
release.

You were so convinced that everything was right (after all, the tests
passed :-), and now you're admitting there were still problems.  So
prudence requires me to assume that there will be more problems,
because the new version is more complicated than the previous one.

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


From skip@mojam.com  Sun Jun 22 13:00:18 2003
From: skip@mojam.com (Skip Montanaro)
Date: Sun, 22 Jun 2003 07:00:18 -0500
Subject: [Python-Dev] Weekly Python Bug/Patch Summary
Message-ID: <200306221200.h5MC0IU00654@manatee.mojam.com>

Bug/Patch Summary
-----------------

361 open / 3746 total bugs (-2)
164 open / 2229 total patches (+7)

New Bugs
--------

AssertionError from urllib.retrieve / httplib (2003-06-15)
	http://python.org/sf/755080
Tutorial: 4.7.2 Keyword Arguments **name output order wrong (2003-06-16)
	http://python.org/sf/755564
os module: Need a better description of "mode" (2003-06-16)
	http://python.org/sf/755617
complex pow() crash on Alpha (2003-06-17)
	http://python.org/sf/756093
Calling socket.recv() with a large number breaks (2003-06-17)
	http://python.org/sf/756104
Recursion limit too high for MacOSX (2003-06-18)
	http://python.org/sf/756576
Ms VC 2003 not supported (2003-06-18)
	http://python.org/sf/756842
SIGSEGV causes hung threads (Linux) (2003-06-18)
	http://python.org/sf/756924
can't CNTRL-C when running os.system in a thread (2003-06-18)
	http://python.org/sf/756940
FutureWarning: %u/%o/%x/%X of negative int will return a sig (2003-06-19)
	http://python.org/sf/757365
irreproducable segfault on int(1e100) (2003-06-19)
	http://python.org/sf/757520
Need to register PythonLauncher as handler for .py (2003-06-19)
	http://python.org/sf/757542
Mac/OSX/README outdated (2003-06-19)
	http://python.org/sf/757567
logging module docs (2003-06-20)
	http://python.org/sf/757821
Additional index items, other minor details (2003-06-20)
	http://python.org/sf/757822
socket timeout exception unhelpful (2003-06-20)
	http://python.org/sf/758239
asyncore with non-default map problems (2003-06-20)
	http://python.org/sf/758241
test_sax fails on python 2.2.3 & patch for regrtest.py (2003-06-21)
	http://python.org/sf/758504
IDE needs to remember status of interactive window (2003-06-21)
	http://python.org/sf/758565
IDE preferences cleanup (2003-06-21)
	http://python.org/sf/758566
cgi module should handle large post attack (2003-06-21)
	http://python.org/sf/758665

New Patches
-----------

SSL crash interpreter on error (2003-06-15)
	http://python.org/sf/754870
Generate rpm filelist including directories (2003-06-16)
	http://python.org/sf/755286
allow HTMLParser to continue after a parse error (2003-06-16)
	http://python.org/sf/755660
improve HTMLParser attribute processing regexps (2003-06-16)
	http://python.org/sf/755670
755617: better docs for os.chmod (2003-06-16)
	http://python.org/sf/755677
Allow socket.inet_aton("255.255.255.255") on Windows (2003-06-17)
	http://python.org/sf/756021
re reads an uninitialized memory (2003-06-17)
	http://python.org/sf/756032
itertools roundrobin() and window() (2003-06-17)
	http://python.org/sf/756253
test_itertools for roundrobin() and window() (2003-06-17)
	http://python.org/sf/756255
Bare except in ZipFile.testzip() (2003-06-18)
	http://python.org/sf/756996
Fixing recursive problem in SRE (2003-06-19)
	http://python.org/sf/757624
Using __slots__ with str derived classes can cause segfault (2003-06-20)
	http://python.org/sf/757997

Closed Bugs
-----------

Programs using Tkinter sometimes can't shut down (Windows) (2000-10-06)
	http://python.org/sf/216289
Codec naming scheme and aliasing support (2000-12-12)
	http://python.org/sf/225476
WIN32 os.path.normpath('./') incorrect (2002-01-31)
	http://python.org/sf/511261
raw_input non-ascii failure on Linux/KDE (2002-03-07)
	http://python.org/sf/527022
Framework.mainloop() - multiple threads (2002-04-05)
	http://python.org/sf/539990
Hint for speeding up cPickle (2002-08-07)
	http://python.org/sf/592112
IDE look and feel (2002-09-11)
	http://python.org/sf/607814
Can't run script from IDLE (2002-12-01)
	http://python.org/sf/646730
make error reporting better like cgi (2002-12-16)
	http://python.org/sf/654558
Freeze can not be made to exclude implicits (2003-02-11)
	http://python.org/sf/684679
Compiler Limits (indentation) (2003-03-10)
	http://python.org/sf/700827
Lookup of Mac error string can mess up resfile chain (2003-03-29)
	http://python.org/sf/711967
app-building with Bundlebuilder for framework builds (2003-04-18)
	http://python.org/sf/723562
OSX installer .pkg file permissions (2003-05-02)
	http://python.org/sf/731631
IMAP4_SSL broken (2003-05-19)
	http://python.org/sf/739909
_locale in Python-2.3b1/Tru64Unix 5.1A doesn't link (2003-05-22)
	http://python.org/sf/741843
exec documentation not updated (2003-06-06)
	http://python.org/sf/750092
Thread in threading.py can only be started once (2003-06-09)
	http://python.org/sf/751260
cPickle doesn't raise error, pickle does (recursiondepth) (2003-06-09)
	http://python.org/sf/751276
2.2.3 Latex documentation missing from web page? (2003-06-10)
	http://python.org/sf/751933
graminit.[ch] don't build on windows (2003-06-10)
	http://python.org/sf/751956
Object destruction is broken for slots (2003-06-10)
	http://python.org/sf/751998
print in __getattr__ causes seg fault (2003-06-10)
	http://python.org/sf/752221
classmethod abuse --> SystemError (2003-06-12)
	http://python.org/sf/753451
Installing idle from new location (2003-06-12)
	http://python.org/sf/753518

Closed Patches
--------------

plain text enhancement for cgitb (2002-06-15)
	http://python.org/sf/569574
zlib.decompressobj under-described. (2002-11-18)
	http://python.org/sf/640236
Build _tkinter in setup.jaguar.py (2002-11-27)
	http://python.org/sf/644920
Don't FPE on FreeBSD... (2002-11-28)
	http://python.org/sf/645382
DESTDIR improvement (2003-05-12)
	http://python.org/sf/736413
Put DEFS back to Makefile.pre.in (2003-05-12)
	http://python.org/sf/736417
Bug fix 750092: exec doesn't need newline (2003-06-08)
	http://python.org/sf/751038


From andymac@bullseye.apana.org.au  Sun Jun 22 13:49:34 2003
From: andymac@bullseye.apana.org.au (Andrew MacIntyre)
Date: Sun, 22 Jun 2003 22:49:34 +1000 (EST)
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030620203223.GA30958@ibook>
References: <LNBBLJKPBEHFEDALKOLCKEMEEKAB.tim.one@comcast.net>
 <032b01c33710$d6486920$ced241d5@hagrid> <20030620151654.GC23141@ibook>
 <20030620203223.GA30958@ibook>
Message-ID: <20030622223139.L59221@bullseye.apana.org.au>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--0-756315873-1056286174=:59221
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 20 Jun 2003, Gustavo Niemeyer wrote:

> > implementation. I'm also checking if it is possible to move some of
> > the intelligence in MAX_REPEAT_ONE to MAX_REPEAT.
>
> Good news and bad news. I was able to greatly improve some cases
> using the priciples of MAX_REPEAT_ONE, but I also got a problem
> in the current implementation. I'll be working on it.

Not sure whether this refers to the second version of the patch.

I've tried this (2nd version of patch) on both FreeBSD 4.8 and 5.1.

gcc 2.95 (4.8) barfs on the code, but gcc 3.2.2 (5.1) is ok - attached
patch shuts 2.95 up.

Unfortunately, in both cases test_pyclbr goes off with the pixies with the
patch applied.

Interestingly, interrupting with a Ctrl-C produces a segmentation fault,
and the gdb backtrace is the same for both platforms (4.8/5.1).  If the bt
is useful, I can send it direct.

Don't yet know what other tests might be misbehaving, having only gotten
as far as test_pyclbr.

Regards,
Andrew.

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac@pcug.org.au             (alt) |        Belconnen  ACT  2616
Web:    http://www.andymac.org/               |        Australia
--0-756315873-1056286174=:59221
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="_sre.c.exp.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <20030622224934.I59221@bullseye.apana.org.au>
Content-Description: _sre.c.gcc295.patch
Content-Disposition: attachment; filename="_sre.c.exp.patch"

KioqIF9zcmUuYy5iYWsJU3VuIEp1biAyMiAyMjoxMjoxOCAyMDAzDQotLS0g
X3NyZS5jCVN1biBKdW4gMjIgMjE6NDI6NTUgMjAwMw0KKioqKioqKioqKioq
KioqDQoqKiogOTM1LDk0NSAqKioqDQogICAgICAgICAgICAgIFRSQUNFKCgi
fCVwfCVwfEdST1VQUkVGICVkXG4iLCBwYXR0ZXJuLCBwdHIsIHBhdHRlcm5b
MF0pKTsNCiAgICAgICAgICAgICAgaSA9IHBhdHRlcm5bMF07DQogICAgICAg
ICAgICAgIHsNCiAgICAgICAgICAgICAgICAgIGludCBncm91cHJlZiA9IGkr
aTsNCiAgICAgICAgICAgICAgICAgIGlmIChncm91cHJlZiA+PSBzdGF0ZS0+
bGFzdG1hcmspDQogICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIDA7DQoh
ICAgICAgICAgICAgICAgICBTUkVfQ0hBUiogcCA9IChTUkVfQ0hBUiopIHN0
YXRlLT5tYXJrW2dyb3VwcmVmXTsNCiEgICAgICAgICAgICAgICAgIFNSRV9D
SEFSKiBlID0gKFNSRV9DSEFSKikgc3RhdGUtPm1hcmtbZ3JvdXByZWYrMV07
DQogICAgICAgICAgICAgICAgICBpZiAoIXAgfHwgIWUgfHwgZSA8IHApDQog
ICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIDA7DQogICAgICAgICAgICAg
ICAgICB3aGlsZSAocCA8IGUpIHsNCi0tLSA5MzUsOTQ3IC0tLS0NCiAgICAg
ICAgICAgICAgVFJBQ0UoKCJ8JXB8JXB8R1JPVVBSRUYgJWRcbiIsIHBhdHRl
cm4sIHB0ciwgcGF0dGVyblswXSkpOw0KICAgICAgICAgICAgICBpID0gcGF0
dGVyblswXTsNCiAgICAgICAgICAgICAgew0KKyAgICAgICAgICAgICAgICAg
U1JFX0NIQVIqIHA7DQorICAgICAgICAgICAgICAgICBTUkVfQ0hBUiogZTsN
CiAgICAgICAgICAgICAgICAgIGludCBncm91cHJlZiA9IGkraTsNCiAgICAg
ICAgICAgICAgICAgIGlmIChncm91cHJlZiA+PSBzdGF0ZS0+bGFzdG1hcmsp
DQogICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIDA7DQohICAgICAgICAg
ICAgICAgICBwID0gKFNSRV9DSEFSKikgc3RhdGUtPm1hcmtbZ3JvdXByZWZd
Ow0KISAgICAgICAgICAgICAgICAgZSA9IChTUkVfQ0hBUiopIHN0YXRlLT5t
YXJrW2dyb3VwcmVmKzFdOw0KICAgICAgICAgICAgICAgICAgaWYgKCFwIHx8
ICFlIHx8IGUgPCBwKQ0KICAgICAgICAgICAgICAgICAgICAgIHJldHVybiAw
Ow0KICAgICAgICAgICAgICAgICAgd2hpbGUgKHAgPCBlKSB7DQoqKioqKioq
KioqKioqKioNCioqKiA5NTYsOTY2ICoqKioNCiAgICAgICAgICAgICAgVFJB
Q0UoKCJ8JXB8JXB8R1JPVVBSRUZfSUdOT1JFICVkXG4iLCBwYXR0ZXJuLCBw
dHIsIHBhdHRlcm5bMF0pKTsNCiAgICAgICAgICAgICAgaSA9IHBhdHRlcm5b
MF07DQogICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgIGludCBn
cm91cHJlZiA9IGkraTsNCiAgICAgICAgICAgICAgICAgIGlmIChncm91cHJl
ZiA+PSBzdGF0ZS0+bGFzdG1hcmspDQogICAgICAgICAgICAgICAgICAgICAg
cmV0dXJuIDA7DQohICAgICAgICAgICAgICAgICBTUkVfQ0hBUiogcCA9IChT
UkVfQ0hBUiopIHN0YXRlLT5tYXJrW2dyb3VwcmVmXTsNCiEgICAgICAgICAg
ICAgICAgIFNSRV9DSEFSKiBlID0gKFNSRV9DSEFSKikgc3RhdGUtPm1hcmtb
Z3JvdXByZWYrMV07DQogICAgICAgICAgICAgICAgICBpZiAoIXAgfHwgIWUg
fHwgZSA8IHApDQogICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIDA7DQog
ICAgICAgICAgICAgICAgICB3aGlsZSAocCA8IGUpIHsNCi0tLSA5NTgsOTcw
IC0tLS0NCiAgICAgICAgICAgICAgVFJBQ0UoKCJ8JXB8JXB8R1JPVVBSRUZf
SUdOT1JFICVkXG4iLCBwYXR0ZXJuLCBwdHIsIHBhdHRlcm5bMF0pKTsNCiAg
ICAgICAgICAgICAgaSA9IHBhdHRlcm5bMF07DQogICAgICAgICAgICAgIHsN
CisgICAgICAgICAgICAgICAgIFNSRV9DSEFSKiBwOw0KKyAgICAgICAgICAg
ICAgICAgU1JFX0NIQVIqIGU7DQogICAgICAgICAgICAgICAgICBpbnQgZ3Jv
dXByZWYgPSBpK2k7DQogICAgICAgICAgICAgICAgICBpZiAoZ3JvdXByZWYg
Pj0gc3RhdGUtPmxhc3RtYXJrKQ0KICAgICAgICAgICAgICAgICAgICAgIHJl
dHVybiAwOw0KISAgICAgICAgICAgICAgICAgcCA9IChTUkVfQ0hBUiopIHN0
YXRlLT5tYXJrW2dyb3VwcmVmXTsNCiEgICAgICAgICAgICAgICAgIGUgPSAo
U1JFX0NIQVIqKSBzdGF0ZS0+bWFya1tncm91cHJlZisxXTsNCiAgICAgICAg
ICAgICAgICAgIGlmICghcCB8fCAhZSB8fCBlIDwgcCkNCiAgICAgICAgICAg
ICAgICAgICAgICByZXR1cm4gMDsNCiAgICAgICAgICAgICAgICAgIHdoaWxl
IChwIDwgZSkgew0KKioqKioqKioqKioqKioqDQoqKiogOTc4LDk5MCAqKioq
DQogICAgICAgICAgICAgIC8qIDxHUk9VUFJFRl9FWElTVFM+IDxncm91cD4g
PHNraXA+IGNvZGV5ZXMgPEpVTVA+IGNvZGVubyAuLi4gKi8NCiAgICAgICAg
ICAgICAgaSA9IHBhdHRlcm5bMF07DQogICAgICAgICAgICAgIHsNCiAgICAg
ICAgICAgICAgICAgIGludCBncm91cHJlZiA9IGkraTsNCiAgICAgICAgICAg
ICAgICAgIGlmIChncm91cHJlZiA+PSBzdGF0ZS0+bGFzdG1hcmspIHsNCiAg
ICAgICAgICAgICAgICAgICAgICBwYXR0ZXJuICs9IHBhdHRlcm5bMV07DQog
ICAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQogICAgICAgICAgICAgICAg
ICB9DQohICAgICAgICAgICAgICAgICBTUkVfQ0hBUiogcCA9IChTUkVfQ0hB
UiopIHN0YXRlLT5tYXJrW2dyb3VwcmVmXTsNCiEgICAgICAgICAgICAgICAg
IFNSRV9DSEFSKiBlID0gKFNSRV9DSEFSKikgc3RhdGUtPm1hcmtbZ3JvdXBy
ZWYrMV07DQogICAgICAgICAgICAgICAgICBpZiAoIXAgfHwgIWUgfHwgZSA8
IHApIHsNCiAgICAgICAgICAgICAgICAgICAgICBwYXR0ZXJuICs9IHBhdHRl
cm5bMV07DQogICAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQotLS0gOTgy
LDk5NiAtLS0tDQogICAgICAgICAgICAgIC8qIDxHUk9VUFJFRl9FWElTVFM+
IDxncm91cD4gPHNraXA+IGNvZGV5ZXMgPEpVTVA+IGNvZGVubyAuLi4gKi8N
CiAgICAgICAgICAgICAgaSA9IHBhdHRlcm5bMF07DQogICAgICAgICAgICAg
IHsNCisgICAgICAgICAgICAgICAgIFNSRV9DSEFSKiBwOw0KKyAgICAgICAg
ICAgICAgICAgU1JFX0NIQVIqIGU7DQogICAgICAgICAgICAgICAgICBpbnQg
Z3JvdXByZWYgPSBpK2k7DQogICAgICAgICAgICAgICAgICBpZiAoZ3JvdXBy
ZWYgPj0gc3RhdGUtPmxhc3RtYXJrKSB7DQogICAgICAgICAgICAgICAgICAg
ICAgcGF0dGVybiArPSBwYXR0ZXJuWzFdOw0KICAgICAgICAgICAgICAgICAg
ICAgIGJyZWFrOw0KICAgICAgICAgICAgICAgICAgfQ0KISAgICAgICAgICAg
ICAgICAgcCA9IChTUkVfQ0hBUiopIHN0YXRlLT5tYXJrW2dyb3VwcmVmXTsN
CiEgICAgICAgICAgICAgICAgIGUgPSAoU1JFX0NIQVIqKSBzdGF0ZS0+bWFy
a1tncm91cHJlZisxXTsNCiAgICAgICAgICAgICAgICAgIGlmICghcCB8fCAh
ZSB8fCBlIDwgcCkgew0KICAgICAgICAgICAgICAgICAgICAgIHBhdHRlcm4g
Kz0gcGF0dGVyblsxXTsNCiAgICAgICAgICAgICAgICAgICAgICBicmVhazsN
Cg==

--0-756315873-1056286174=:59221--


From ben@dadsetan.com  Sun Jun 22 14:58:14 2003
From: ben@dadsetan.com (Behrang Dadsetan)
Date: Sun, 22 Jun 2003 15:58:14 +0200
Subject: [Python-Dev] Update for os.path.expandvars bug 49589
Message-ID: <3EF5B5F6.2090302@dadsetan.com>

Here follows the comment I just added to bug "[ 494589 ] 
os.path.expandvars deletes things on w32".


It concerns some mismatching (buggy) implementation / docstrings / 
comments for the ntpath.py and dospath.py.

(Especially) As it is my first post as well as bugfix try for any 
open-source project, I am very happy receiving constructiv critic.

tim_one is right. There is plenty of dodgy things hiding behind the 
os.path world, especially when it comes to os.path.expandvars()

There are two problems here.
- Mismatch in between the doc strings of the different implementation of 
expandvars and the "official" os.path.expandvars documentation.
- the ntpath and dospath implementations are buggy when compared to 
their comments/docstrings.

About the first problem, the inconsistency created some time ago in 
between the different implementations tasks makes it difficult to choose 
a solution. Everyone will probably agree that all the platform specific 
implementations of expandvars should have the same functionality. The 
one that should be taken over will probably need to be announced by the 
BDFL.

Some rule which should not have let this here happen, and on which I 
believe we all will agree on:
Same interface=same documentation->same functionality

To implement either copy paste exactly the same expandvars definition 
from one platform to another (NT, DOS, POSIX), or somehow rather arrange 
that when there is no specific implementation for the platform, a 
"default" python implementation is used on the os.path level. To 
maximize the fruits of my small work, I would of course prefer that the 
version below becomes the standard and that the documentation get updated.

To be complete, shall the documentation remain unchanged and the 
implementation of dos and nt gets adapted (copied from posix), the mac 
implementation could remain unchanged. But I feel its docstring and its 
documentation should be in line with the rest of the implementations.

So my view point-> same interface, same documentation

For the second problem - as of now a real bug whatever we decide, I 
wrote within this comment (hereafter) a new expandvars version which 
fits the docstring documentation of dospath.py and the comments of 
ntpath.py. Sorry you will be getting no patch from me at the moment 
since sourceforge's anonymous CVS access does not like me. Please note 
that my version borrows alot from the posixpath.py implementation and my 
changes are the ones of a python amateur who is open to critic.

#expandvars() implementation
_varprog = None
_findquotes = None
def expandvars(path):
     """Expand paths containing shell variable substitutions.
     The following rules apply:
         - no expansion within single quotes
         - no escape character, except for '$$' which is translated into '$'
         - ${varname} is accepted.
         - varnames can be made out of letters, digits and the character 
'_'"""
     global _varprog, _findquotes
     if '$' not in path:
         return path
     if not _varprog:
         import re
         _varprog = re.compile(r'\$(\w+|\{[^}]*\}|\$)')
         _findquotes = re.compile("'.*?'")
     quoteareas = []
     i = 0
     while 1:
         quotearea = _findquotes.search(path, i)
         if not quotearea:
             break
         (i, j) = quotearea.span(0)
         quoteareas.append((i, j))
         i = j
     i = 0
     while 1:
         m = _varprog.search(path, i)
         if not m:
             break
         i, j = m.span(0)
         insidequotes=None
         for (quotebegin, quoteend) in quoteareas:
             if quotebegin < i and quoteend > i:
                 insidequotes=1
                 break
         if insidequotes:
             i = j
             continue
         name = m.group(1)
         if name[:1] == '$':
             path = path[:i] + '$' + path[j:]
             i = i + 1
         else:
             if name[:1] == '{' and name[-1:] == '}':
                 name = name[1:-1]
             if os.environ.has_key(name):
                 tail = path[j:]
                 path = path[:i] + os.environ[name]
                 i = len(path)
                 path = path + tail
             else:
                 i = j
     return path

Regards, Ben.



From niemeyer@conectiva.com  Sun Jun 22 15:20:25 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Sun, 22 Jun 2003 11:20:25 -0300
Subject: [Python-Dev] More work on SRE
In-Reply-To: <200306220748.h5M7mOB03928@pcp02138704pcs.reston01.va.comcast.net>
References: <20030622015216.GA11520@ibook> <200306220748.h5M7mOB03928@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20030622142024.GA14267@ibook>

> > There's a new version of the patch
> > 
> >     http://www.python.org/sf/757624
> > 
> > I understood there was some problems with the first implementation,
> > and changed some aspects of how the new implementation works to fix them.
> 
> BDFL Pronouncement: let's not add this to the 2.3 release.  We can add
> it to CVS after 2.3 is out the door and it will be included in the 2.3
> release.
> 
> You were so convinced that everything was right (after all, the tests
> passed :-), and now you're admitting there were still problems.  So

Unfortunately, I was wrong. Some tests in re_tests were failing, and
I couldn't see that until I've fixed the two tests in test_re.py that
failed *expecting* the recursion explosion (that's something we have
to change, making re_tests.py run even if some test fails in test_re.py).

Btw, I was not convinced everything was right, I was convinced the
implementation was simple enough, and it was ready to be tested further,
and that we could go back easily until 2.3, as you probably remember.

> prudence requires me to assume that there will be more problems,
> because the new version is more complicated than the previous one.

That's why I've sent the message and asked for testers, without
committing the code. I understand your position, and agree partially.
The only point that makes me wonder if it wouldn't be nice to try
adding this to 2.3 is that many bugs were fixed by this implementation,
besides the recursion problem.

Anyway, I'll keep working on it, and testing it, being on 2.3 or not.

-- 
Gustavo Niemeyer
http://niemeyer.net


From niemeyer@conectiva.com  Sun Jun 22 21:24:44 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Sun, 22 Jun 2003 17:24:44 -0300
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <20030622223139.L59221@bullseye.apana.org.au>
References: <LNBBLJKPBEHFEDALKOLCKEMEEKAB.tim.one@comcast.net> <032b01c33710$d6486920$ced241d5@hagrid> <20030620151654.GC23141@ibook> <20030620203223.GA30958@ibook> <20030622223139.L59221@bullseye.apana.org.au>
Message-ID: <20030622202444.GA23705@ibook>

> Not sure whether this refers to the second version of the patch.
[...]

I've just submitted a new patch to SF (version 3) which addresses
these problems. Can you please repeat the test?

Thank you very much!

-- 
Gustavo Niemeyer
http://niemeyer.net


From greg@cosc.canterbury.ac.nz  Mon Jun 23 03:20:34 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Mon, 23 Jun 2003 14:20:34 +1200 (NZST)
Subject: [Python-Dev] Python on dual-processor Macs?
Message-ID: <200306230220.h5N2KYe28820@oma.cosc.canterbury.ac.nz>

I seem to remember a while back there was mention of a bug
that prevented Python from working on dual-processor Macintoshes.

Can anyone tell me:

* Does this bug still exist?

* If so, is it just the classic and/or carbon versions of
  MacPython that are affected, or does it apply to the
  unix command-line version as well?

This is rather important to me right now, since I'm thinking
of getting a new Mac, and I don't want to end up with 
something that won't run Python!

Thanks,

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


From martin@v.loewis.de  Mon Jun 23 07:18:48 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 23 Jun 2003 08:18:48 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <3EF48848.8040707@lemburg.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <3EF453DE.4040301@lemburg.com>
 <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
 <3EF4843E.60901@lemburg.com>
 <m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>
 <3EF48848.8040707@lemburg.com>
Message-ID: <m3smq1iaev.fsf@mira.informatik.hu-berlin.de>

"M.-A. Lemburg" <mal@lemburg.com> writes:

> Why is that ? The proposed APIs will work just like their
> counterparts for the internal Unicode/string conversion which
> have proven to quiet down discussions about choosing ASCII
> as default encoding. I expect the same to happen for the
> Python source code encoding default.

It just occurred to me that these people can put

import warnings
warnings.filterwarnings("ignore", ".*pep-0263", DeprecationWarning)

into site.py to achieve nearly the same effect that they would get
with sys.setsourceencoding.

People are probably concerned about the flood of warnings, and they
want to silence them, so that everything continues to work as it did
before. Ignoring those warnings appears to be the right solution,
then.

If they want to make use of the new features (i.e. non-ASCII in
Unicode literals), they still need to put an encoding declaration into
the file. However they are probably willing to do that, as they are
editing the file, anyway.

Regards,
Martin



From Jack.Jansen@cwi.nl  Mon Jun 23 10:03:51 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Mon, 23 Jun 2003 11:03:51 +0200
Subject: [Python-Dev] Python on dual-processor Macs?
In-Reply-To: <200306230220.h5N2KYe28820@oma.cosc.canterbury.ac.nz>
Message-ID: <9BBCFCCE-A559-11D7-B256-0030655234CE@cwi.nl>

On Monday, Jun 23, 2003, at 04:20 Europe/Amsterdam, Greg Ewing wrote:

> I seem to remember a while back there was mention of a bug
> that prevented Python from working on dual-processor Macintoshes.
>
> Can anyone tell me:
>
> * Does this bug still exist?

No, it was solved in 2.2.1, I think.
>
> * If so, is it just the classic and/or carbon versions of
>   MacPython that are affected, or does it apply to the
>   unix command-line version as well?

Just in MacPython-OS9, the unix-Python of OSX wasn't affected.
And only on OSX in native mode, OS9 and the classic emulator in
OSX didn't exhibit the problem either.

In other words, if you're think of using Python 2.3 on OSX there
is absolutely no problem.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman



From Jack.Jansen@cwi.nl  Mon Jun 23 10:06:28 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Mon, 23 Jun 2003 11:06:28 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <m3smq1iaev.fsf@mira.informatik.hu-berlin.de>
Message-ID: <F954B9DD-A559-11D7-B256-0030655234CE@cwi.nl>

On Monday, Jun 23, 2003, at 08:18 Europe/Amsterdam, Martin v. L=F6wis=20
wrote:

> "M.-A. Lemburg" <mal@lemburg.com> writes:
>
>> Why is that ? The proposed APIs will work just like their
>> counterparts for the internal Unicode/string conversion which
>> have proven to quiet down discussions about choosing ASCII
>> as default encoding. I expect the same to happen for the
>> Python source code encoding default.
>
> It just occurred to me that these people can put
>
> import warnings
> warnings.filterwarnings("ignore", ".*pep-0263", DeprecationWarning)
>
> into site.py to achieve nearly the same effect that they would get
> with sys.setsourceencoding.

It would silence the warnings, but I would guess that if you actually
processed the file (for instance, open it in Idle) you would see
strange characters, no?
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma=20
Goldman



From mal@lemburg.com  Mon Jun 23 10:22:19 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 23 Jun 2003 11:22:19 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <m3smq1iaev.fsf@mira.informatik.hu-berlin.de>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>	<3EF453DE.4040301@lemburg.com>	<m38yrvoa99.fsf@mira.informatik.hu-berlin.de>	<3EF4843E.60901@lemburg.com>	<m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>	<3EF48848.8040707@lemburg.com> <m3smq1iaev.fsf@mira.informatik.hu-berlin.de>
Message-ID: <3EF6C6CB.2030103@lemburg.com>

Martin v. L=F6wis wrote:
> "M.-A. Lemburg" <mal@lemburg.com> writes:
>=20
>=20
>>Why is that ? The proposed APIs will work just like their
>>counterparts for the internal Unicode/string conversion which
>>have proven to quiet down discussions about choosing ASCII
>>as default encoding. I expect the same to happen for the
>>Python source code encoding default.
>=20
>=20
> It just occurred to me that these people can put
>=20
> import warnings
> warnings.filterwarnings("ignore", ".*pep-0263", DeprecationWarning)
>=20
> into site.py to achieve nearly the same effect that they would get
> with sys.setsourceencoding.

I know, but that trick only works in Python 2.3. In Python 2.4 they
would get a SyntaxError and their scripts would simply fail to load.

> People are probably concerned about the flood of warnings, and they
> want to silence them, so that everything continues to work as it did
> before. Ignoring those warnings appears to be the right solution,
> then.

If they are only concerned about the warnings in 2.3, yes,...

> If they want to make use of the new features (i.e. non-ASCII in
> Unicode literals), they still need to put an encoding declaration into
> the file. However they are probably willing to do that, as they are
> editing the file, anyway.

... but some of them are also worried about raising the bar
teaching Python to newbies. They don't want to start the
Python course explaining advanced features like source code
encodings.

--=20
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 23 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium:                        one day left



From andymac@bullseye.apana.org.au  Mon Jun 23 13:55:35 2003
From: andymac@bullseye.apana.org.au (Andrew MacIntyre)
Date: Mon, 23 Jun 2003 22:55:35 +1000 (EST)
Subject: [Python-Dev] non-recursive SRE patch v3 (SF #757624)
In-Reply-To: <20030622202444.GA23705@ibook>
References: <LNBBLJKPBEHFEDALKOLCKEMEEKAB.tim.one@comcast.net>
 <032b01c33710$d6486920$ced241d5@hagrid> <20030620151654.GC23141@ibook>
 <20030620203223.GA30958@ibook> <20030622223139.L59221@bullseye.apana.org.au>
 <20030622202444.GA23705@ibook>
Message-ID: <20030623222903.L73220@bullseye.apana.org.au>

On Sun, 22 Jun 2003, Gustavo Niemeyer wrote:

> > Not sure whether this refers to the second version of the patch.
> [...]
>
> I've just submitted a new patch to SF (version 3) which addresses
> these problems. Can you please repeat the test?

With v3 of the patch, the interpreter survives the full regression test on
both FreeBSD 4.8 (gcc 2.95.3) & FreeBSD 5.1 (gcc 3.2.2).  Just for
completeness, I tested with USE_RECURSION_LIMIT reverted to 10000 on both
systems.

I didn't monitor performance, other than to note that there was no gross
slowdown...

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac@pcug.org.au             (alt) |        Belconnen  ACT  2616
Web:    http://www.andymac.org/               |        Australia


From mats@laplaza.org  Mon Jun 23 15:33:32 2003
From: mats@laplaza.org (Mats Wichmann)
Date: Mon, 23 Jun 2003 08:33:32 -0600
Subject: [Python-Dev] Re: curses module has_key emulation
Message-ID: <5.1.0.14.1.20030623083112.01f05830@mail.laplaza.org>

 > the Lib/curses/has_key.py code looks questionable

I've uploaded a trivial patch for this as 759208
in case anyone has a chance to take a look.



From tim@zope.com  Mon Jun 23 18:28:35 2003
From: tim@zope.com (Tim Peters)
Date: Mon, 23 Jun 2003 13:28:35 -0400
Subject: [Python-Dev] Patch  595601
Message-ID: <BIEJKCLHCIOIHAGOKOLHKEJPGAAA.tim@zope.com>

    http://www.python.org/sf/595601

has been in limbo a long time.  Looks like it popped up in real life, in
Zope last week.

Quickie:  if you let run this long enough, it will die with a segfault (and
under any version of Python):

"""
import threading

class Worker(threading.Thread):
    def __init__(self, f):
        threading.Thread.__init__(self)
        self.f = f

    def run(self):
        for i in xrange(100):
            self.f.write('abc')

def doit():
    f = file('junk.txt', 'wb')
    w = Worker(f)
    w.start()
    f.close()
    w.join()

if __name__ == '__main__':
    while True:
        print '.',
        doit()
"""

Who here cares?



From skip@pobox.com  Mon Jun 23 19:10:50 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 23 Jun 2003 13:10:50 -0500
Subject: [Python-Dev] Patch  595601
In-Reply-To: <BIEJKCLHCIOIHAGOKOLHKEJPGAAA.tim@zope.com>
References: <BIEJKCLHCIOIHAGOKOLHKEJPGAAA.tim@zope.com>
Message-ID: <16119.17066.64550.621436@montanaro.dyndns.org>

    Tim>     http://www.python.org/sf/595601

    Tim> has been in limbo a long time.  Looks like it popped up in real
    Tim> life, in Zope last week.

    Tim> Quickie: if you let run this long enough, it will die with a
    Tim> segfault (and under any version of Python):

    ...

Isn't this a case of "so don't do that"?  I've never encountered this
before, but then I don't close files in one thread while another holds a
reference.

Would it be reasonable to raise an error or warning if a file's close()
method was called when the reference count was greater than 1?

Skip



From barry@python.org  Mon Jun 23 19:18:02 2003
From: barry@python.org (Barry Warsaw)
Date: 23 Jun 2003 14:18:02 -0400
Subject: [Python-Dev] Patch  595601
In-Reply-To: <16119.17066.64550.621436@montanaro.dyndns.org>
References: <BIEJKCLHCIOIHAGOKOLHKEJPGAAA.tim@zope.com>
 <16119.17066.64550.621436@montanaro.dyndns.org>
Message-ID: <1056392281.29545.43.camel@barry>

On Mon, 2003-06-23 at 14:10, Skip Montanaro wrote:

> Would it be reasonable to raise an error or warning if a file's close()
> method was called when the reference count was greater than 1?

There could be lots of reasons why a file's refcount was greater than 1
without threads entering into the picture.

-Barry




From skip@pobox.com  Mon Jun 23 19:29:58 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 23 Jun 2003 13:29:58 -0500
Subject: [Python-Dev] Patch  595601
In-Reply-To: <1056392281.29545.43.camel@barry>
References: <BIEJKCLHCIOIHAGOKOLHKEJPGAAA.tim@zope.com>
 <16119.17066.64550.621436@montanaro.dyndns.org>
 <1056392281.29545.43.camel@barry>
Message-ID: <16119.18214.476823.133840@montanaro.dyndns.org>

    >> Would it be reasonable to raise an error or warning if a file's
    >> close() method was called when the reference count was greater than
    >> 1?

    Barry> There could be lots of reasons why a file's refcount was greater
    Barry> than 1 without threads entering into the picture.

Yeah, but they probably all represent some sort of bug.  How about a warning
which is disabled by default but which the programmer can enable?

Skip


From tim@zope.com  Mon Jun 23 19:32:35 2003
From: tim@zope.com (Tim Peters)
Date: Mon, 23 Jun 2003 14:32:35 -0400
Subject: [Python-Dev] Patch  595601
In-Reply-To: <16119.17066.64550.621436@montanaro.dyndns.org>
Message-ID: <BIEJKCLHCIOIHAGOKOLHOEKFGAAA.tim@zope.com>

[Skip Montanaro]
> Isn't this a case of "so don't do that"?

I think so, but it's apparently debatable (since people at Zope Corp are
debating it <wink>), and it doesn't excuse Python from segfaulting even if
so.

> I've never encountered this before, but then I don't close files in one
> thread while another holds a reference.

There's no problem with closing a shared file; the problem can arise only if
one thread is trying to "do something" with a file at the same time another
thread is trying to close that file.

> Would it be reasonable to raise an error or warning if a file's
> close() method was called when the reference count was greater than 1?

I don't think so.  Shane Hathaway sketched an approach adding (in effect) an
"in use" count to the FILE* contained by a Python file object.  That count
would be incremented and decremented, under protection of the GIL, around
pieces of implementation code that passed on the FILE*.  *Then* it would
make sense to raise an exception if a close() call occurred while that count
was above its initial value.  This count is independent of how many
references there may be to the Python file object.



From tim@zope.com  Mon Jun 23 19:34:13 2003
From: tim@zope.com (Tim Peters)
Date: Mon, 23 Jun 2003 14:34:13 -0400
Subject: [Python-Dev] Patch  595601
In-Reply-To: <16119.18214.476823.133840@montanaro.dyndns.org>
Message-ID: <BIEJKCLHCIOIHAGOKOLHEEKGGAAA.tim@zope.com>

[Skip Montanaro]
> Yeah, but they probably all represent some sort of bug.

There's nothing fishy about having many references to a single file object.

>>> import sys
>>> sys.getrefcount(sys.stdout)
5
>>>

> How about a warning which is disabled by default but which the
> programmer can enable?

It's not addressing the right problem, and wouldn't stop the segfaults
anyway.



From shane@zope.com  Mon Jun 23 19:43:43 2003
From: shane@zope.com (Shane Hathaway)
Date: Mon, 23 Jun 2003 14:43:43 -0400
Subject: [Python-Dev] Patch  595601
In-Reply-To: <16119.17066.64550.621436@montanaro.dyndns.org>
References: <BIEJKCLHCIOIHAGOKOLHKEJPGAAA.tim@zope.com> <16119.17066.64550.621436@montanaro.dyndns.org>
Message-ID: <3EF74A5F.7030609@zope.com>

Skip Montanaro wrote:
>     Tim>     http://www.python.org/sf/595601
> 
>     Tim> has been in limbo a long time.  Looks like it popped up in real
>     Tim> life, in Zope last week.
> 
>     Tim> Quickie: if you let run this long enough, it will die with a
>     Tim> segfault (and under any version of Python):
> 
>     ...
> 
> Isn't this a case of "so don't do that"?  I've never encountered this
> before, but then I don't close files in one thread while another holds a
> reference.
> 
> Would it be reasonable to raise an error or warning if a file's close()
> method was called when the reference count was greater than 1?

I think it would be very reasonable to raise an error if a file's 
close() method is called while another thread is executing a system call 
involving that file.  The Python refcount doesn't provide that 
information, so Jeremy, Tim, Barry, and I have been discussing the idea 
of maintaining a special refcount on PyFileObjects.  The new counter 
would be incremented before system calls involving f->f_fp and 
decremented afterward.  The counter would provide to the close() method 
enough information to know it should raise an error instead of closing 
the file.

What we're not sure of is whether we should be concerned about leaking 
file descriptors due to close() failing.  We'd also like some 
confirmation that fixing this bug is worth a small burden of complexity.

Shane

P.S. I think this is my First Post on Python-dev.  Howdy, all!



From jeremy@zope.com  Mon Jun 23 20:13:34 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: Mon, 23 Jun 2003 15:13:34 -0400
Subject: [Python-Dev] Patch  595601
In-Reply-To: <3EF74A5F.7030609@zope.com>
Message-ID: <web-1720541@digicool.com>

On Mon, 23 Jun 2003 14:43:43 -0400
 Shane Hathaway <shane@zope.com> wrote:
> 
> What we're not sure of is whether we should be concerned
> about leaking file descriptors due to close() failing.
>  We'd also like some confirmation that fixing this bug is
> worth a small burden of complexity.

I'm not yet comfortable with close() raising an exception.
 Maybe I should just get over it.  Shane's suggestion of
marking the object as failed and having the overlapping
operation raise a different exception is interesting.  It
gives the programmer clear indication that something went
wrong, but don't cause close() to fail.  It may be too
complicated, though: Say the overlapping read() fails; then
you've got two errors you want to report.

I think it's clear we should fix this, but it's not clear
when.  If the fix is complicated enough, I think it can
wait for 2.4.

> P.S. I think this is my First Post on Python-dev.  Howdy,
> all!

You've been overdue here.

Jeremy


From shane@zope.com  Mon Jun 23 20:31:50 2003
From: shane@zope.com (Shane Hathaway)
Date: Mon, 23 Jun 2003 15:31:50 -0400
Subject: [Python-Dev] Patch  595601
In-Reply-To: <web-1720541@digicool.com>
References: <3EF74A5F.7030609@zope.com> <web-1720541@digicool.com>
Message-ID: <3EF755A6.8030209@zope.com>

Jeremy Hylton wrote:
> On Mon, 23 Jun 2003 14:43:43 -0400
>  Shane Hathaway <shane@zope.com> wrote:
>>P.S. I think this is my First Post on Python-dev.  Howdy,
>>all!
> 
> You've been overdue here.

To be honest, I've been avoiding this list because I knew I'd like it 
too much, leading to less time spent with my family.  Maybe I'll be OK 
if I only read this list during certain hours of the day. :-)

http://hathaway.freezope.org

Shane



From martin@v.loewis.de  Mon Jun 23 22:32:18 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 23 Jun 2003 23:32:18 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <F954B9DD-A559-11D7-B256-0030655234CE@cwi.nl>
References: <F954B9DD-A559-11D7-B256-0030655234CE@cwi.nl>
Message-ID: <m3n0g81nvh.fsf@mira.informatik.hu-berlin.de>

Jack Jansen <Jack.Jansen@cwi.nl> writes:

> It would silence the warnings, but I would guess that if you actually
> processed the file (for instance, open it in Idle) you would see
> strange characters, no?

Depends on the file, of course. Most likely, you wouldn't.

Regards,
Martin


From martin@v.loewis.de  Mon Jun 23 22:33:49 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 23 Jun 2003 23:33:49 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <3EF6C6CB.2030103@lemburg.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <3EF453DE.4040301@lemburg.com>
 <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
 <3EF4843E.60901@lemburg.com>
 <m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>
 <3EF48848.8040707@lemburg.com>
 <m3smq1iaev.fsf@mira.informatik.hu-berlin.de>
 <3EF6C6CB.2030103@lemburg.com>
Message-ID: <m3isqw1nsy.fsf@mira.informatik.hu-berlin.de>

"M.-A. Lemburg" <mal@lemburg.com> writes:

> ... but some of them are also worried about raising the bar
> teaching Python to newbies. They don't want to start the
> Python course explaining advanced features like source code
> encodings.

They don't have to. All they have to do is to arrange IDLE so that it
always stores files as UTF-8 with BOM, and then everything will work
out just fine, with no need of teaching.

Regards,
Martin



From greg@cosc.canterbury.ac.nz  Tue Jun 24 00:17:01 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 24 Jun 2003 11:17:01 +1200 (NZST)
Subject: [Python-Dev] Python on dual-processor Macs?
In-Reply-To: <9BBCFCCE-A559-11D7-B256-0030655234CE@cwi.nl>
Message-ID: <200306232317.h5NNH1O10468@oma.cosc.canterbury.ac.nz>

Jack Jansen <Jack.Jansen@cwi.nl>:
> > * Does this bug still exist?

> No, it was solved in 2.2.1, I think.
> 
> In other words, if you're think of using Python 2.3 on OSX there
> is absolutely no problem.

That's good to hear! Thanks.

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


From greg@cosc.canterbury.ac.nz  Tue Jun 24 01:24:20 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Tue, 24 Jun 2003 12:24:20 +1200 (NZST)
Subject: [Python-Dev] Patch  595601
In-Reply-To: <3EF74A5F.7030609@zope.com>
Message-ID: <200306240024.h5O0OK310621@oma.cosc.canterbury.ac.nz>

Shane Hathaway <shane@zope.com>:

> I think it would be very reasonable to raise an error if a file's
> close() method is called while another thread is executing a system
> call involving that file.

I don't think raising an exception is the right thing to do here. The
closing thread hasn't really done anything wrong, it just happened to
do the close at a moment that was inconvenient to another thread.

I think the closing should simply be deferred until no operation on
the file is in progress.

Another thing -- is this problem confined to just closing? What if two
threads perform some other operation on a file at the same time --
what stops them from interfering with each other? And whatever it is,
why doesn't it stop closing from interfering with other operations?

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


From tim.one@comcast.net  Tue Jun 24 02:06:29 2003
From: tim.one@comcast.net (Tim Peters)
Date: Mon, 23 Jun 2003 21:06:29 -0400
Subject: [Python-Dev] Patch  595601
In-Reply-To: <200306240024.h5O0OK310621@oma.cosc.canterbury.ac.nz>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEJHELAB.tim.one@comcast.net>

[Greg Ewing]
> I don't think raising an exception is the right thing to do here. The
> closing thread hasn't really done anything wrong, it just happened to
> do the close at a moment that was inconvenient to another thread.

At the level of C streams, it's engaging in undefined behavior.  That's
always wrong, except when Python explicitly decides to provide semantics
beyond what C and POSIX specify.  As far as POSIX is concerned, what happens
when you close a stream while a read or write is in progress is undefined.

> I think the closing should simply be deferred until no operation on
> the file is in progress.

That's a possible semantic Python could layer on top of the platform
facilities, although it's not possible to do so in a bulletproof way (we
simply don't control C-level FILE* objects, and C code can screw us whatever
we try to do here; for example, it's flatly impossible for us to know
whether a file operation is in progress on a FILE* -- we can only add cruft
sufficient to tell whether the a file operation initiated by a Python file
object is in progress on its contained FILE*, and because the Python C API
has several functions that take (or return) FILE*s directly, that's not an
empty qualification).

> Another thing -- is this problem confined to just closing?

The specific segfault at issue is confined to closing, because that's the
only Python file-object operation that resets the Python file object's
stream to NULL.

> What if two threads perform some other operation on a file at the same
> time -- what stops them from interfering with each other?

It depends on the precise operations you have in mind.  If, for example,
you're talking about two threads reading at the same time, then the platform
stream library guarantees-- if it's threadsafe --that the reads will be
serialized.  OTOH, if you're talking about one thread reading and the other
writing, that's engaging in undefined behavior, and there's no predicting
the possible results.  For that matter, you don't need threads at all --
e.g., the effects of writing followed by reading on a single file by a
single thread, without an intervening flush or seek or reweind, are also
undefined.

> And whatever it is, why doesn't it stop closing from interfering with
> other operations?

Because Python resets a Python file object's stream to NULL when a Python
file object is closed, it guarantees a segfault in some cases where the
platform stream library may or may not have gone insane had the program been
mucking with streams directly.



From mal@lemburg.com  Tue Jun 24 08:47:07 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 24 Jun 2003 09:47:07 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <m3isqw1nsy.fsf@mira.informatik.hu-berlin.de>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>	<3EF453DE.4040301@lemburg.com>	<m38yrvoa99.fsf@mira.informatik.hu-berlin.de>	<3EF4843E.60901@lemburg.com>	<m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>	<3EF48848.8040707@lemburg.com>	<m3smq1iaev.fsf@mira.informatik.hu-berlin.de>	<3EF6C6CB.2030103@lemburg.com> <m3isqw1nsy.fsf@mira.informatik.hu-berlin.de>
Message-ID: <3EF801FB.2020309@lemburg.com>

Martin v. L=F6wis wrote:
> "M.-A. Lemburg" <mal@lemburg.com> writes:
>=20
>=20
>>... but some of them are also worried about raising the bar
>>teaching Python to newbies. They don't want to start the
>>Python course explaining advanced features like source code
>>encodings.
>=20
> They don't have to. All they have to do is to arrange IDLE so that it
> always stores files as UTF-8 with BOM, and then everything will work
> out just fine, with no need of teaching.

That's a good hint, but it only works with IDLE and Notepad,
doesn't it ? Other editors or Python IDEs will probably need
some more time to grow such a feature.

--=20
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Jun 24 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________



From guido@python.org  Tue Jun 24 09:06:26 2003
From: guido@python.org (Guido van Rossum)
Date: Tue, 24 Jun 2003 04:06:26 -0400
Subject: [Python-Dev] Patch 595601
In-Reply-To: "Your message of Mon, 23 Jun 2003 21:06:29 EDT."
 <LNBBLJKPBEHFEDALKOLCEEJHELAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCEEJHELAB.tim.one@comcast.net>
Message-ID: <200306240806.h5O86Rn15730@pcp02138704pcs.reston01.va.comcast.net>

> [Greg Ewing]
> > I don't think raising an exception is the right thing to do here. The
> > closing thread hasn't really done anything wrong, it just happened to
> > do the close at a moment that was inconvenient to another thread.

I disagree that the thread has done nothing wrong: if one thread is
closing a file that another thread is still reading, the whole
application is buggy, and if raising an exception in close() is the
most expedient way to tell the application that it is buggy, that's
fine with me.  The application needs to be fixed anyway.

[Tim]
> At the level of C streams, it's engaging in undefined behavior.  That's
> always wrong, except when Python explicitly decides to provide semantics
> beyond what C and POSIX specify.  As far as POSIX is concerned, what happens
> when you close a stream while a read or write is in progress is undefined.

In such cases, Python ought to provide specified behavior beyond POSIX
that at least guarantees that a Python program won't core dump or
otherwise get into an undefined or unusable state as a result of
engaging in such behavior.

BTW, I try to have a practical attitude about behavior that standards
don't define.  I care about undefined behavior that is actually
observed on some platform we (try to) support.  For example, what
happens when int arithmetic overflows is undefined by the C std, but
we don't guard against this because in practice it is harmless enough.
OTOH if closing a file that's being read by another thread can cause
crashes on some platforms, Python should guard against this.

We don't have the resources to guard against everything that standards
call undefined; and there are lots of things that you want to do that
can only be done by using undefined things: platforms often violate
standards, and/or define things that the standard leaves undefined.

As Tim knows, 100% standard-compliant life would be very dull.

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


From randy.gamage@modicon.com  Tue Jun 24 18:38:41 2003
From: randy.gamage@modicon.com (randy.gamage@modicon.com)
Date: Tue, 24 Jun 2003 13:38:41 -0400
Subject: [Python-Dev] cookie support for FancyURLopener?
Message-ID: <OFA782656D.7D149A1D-ON85256D4F.00608E00-85256D4F.0060ED2D@modicon.com>

Hello,
I have never contributed to the python source, but I am considering adding
cookie support to the FancyURLopener library, especially in the case of a
redirect, in which a cookie is issued with the 302 message, and this cookie
is required to access the new page.

I thought I would check if this is in progress, or if there are objections
to this idea, before spending any time on it.

Thanks for your input,

Randy




From martin@v.loewis.de  Tue Jun 24 18:43:07 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 24 Jun 2003 19:43:07 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <3EF801FB.2020309@lemburg.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <3EF453DE.4040301@lemburg.com>
 <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
 <3EF4843E.60901@lemburg.com>
 <m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>
 <3EF48848.8040707@lemburg.com>
 <m3smq1iaev.fsf@mira.informatik.hu-berlin.de>
 <3EF6C6CB.2030103@lemburg.com>
 <m3isqw1nsy.fsf@mira.informatik.hu-berlin.de>
 <3EF801FB.2020309@lemburg.com>
Message-ID: <m3k7bbz80k.fsf@mira.informatik.hu-berlin.de>

"M.-A. Lemburg" <mal@lemburg.com> writes:

> That's a good hint, but it only works with IDLE and Notepad,
> doesn't it ? Other editors or Python IDEs will probably need
> some more time to grow such a feature.

Correct. However, which other editors are commonly used to teach
Python?

Regards,
Martin



From rowen@cesmail.net  Tue Jun 24 19:49:07 2003
From: rowen@cesmail.net (Russell E. Owen)
Date: Tue, 24 Jun 2003 11:49:07 -0700
Subject: [Python-Dev] proposed Tkinter change; any likelihood of acceptance?
Message-ID: <rowen-71B780.11490724062003@main.gmane.org>

I'd like to introduce a small enhancement to Tkinter, but would like 
some idea of whether it has a chance of acceptance before proceeding too 
far (e.g. before checking in a patch).

The primary change is to add a "name" argument to the Variable.__init__, 
bringing it in line with other Tkinter classes. The justification is to 
allow users to create new Tkinter variables that point to existing tcl 
variables (e.g. somewhat similar to nametowidget). In some cases this 
may be more convenient than using setvar and getvar.

Subtlety:
- A new __eq__ method makes two Tkinter variables compare as equal if 
they are of the same type and have the same tcl name.

If it is not overreaching, I'd like to introduce a few related changes 
at the same time.

1) add a "value" argument to Variable.__init__. This would set the 
initial value of the new variable -- a feature I've long wanted.

Subtlety:
- If "name" is specified and the variable already exists, then "value" 
is ignored (so the existing value is preserved). One could always ignore 
"value" if the variable exists, but I suspect users would prefer to 
assume that newly created auto-named variables will be properly 
initialized to some default value.

2) add a new function "nametovariable" which returns a Tkinter variable 
given the name of a tcl variable.

Subtleties:
- To return a Tkinter variable of the correct class, this requires 
changing the auto naming scheme for Tkinter variables. I propose 
PY_class_num where class is the appropriate subclass of Variable. This 
is the only change that has any danger of affecting existing code.
- If the name does not meet the criteria, a StringVar is returned
- If the tcl variable does not exist, an exception is raised. This is 
not necesarry, but prevents accidentaly creating a new variable when one 
was trying to point to an existing one.

If this is too much of a change for 2.3b1 but might be considered for 
later releases, I'd like some idea if I should submit any of it now or 
wait or what.

-- Russell



From damien.morton@acm.org  Tue Jun 24 22:03:41 2003
From: damien.morton@acm.org (Damien Morton)
Date: Tue, 24 Jun 2003 17:03:41 -0400
Subject: [Python-Dev] Python hash function
Message-ID: <001e01c33a94$172753d0$6401a8c0@damien>

Ive been doing some investigation of python hashtables and the hash
function used in Python.

It turns out, that when running pystone.py, as much time is spent in
string_hash() as is spent in lookdict_string(). If you look at
python's hash function, shown below, you can get an idea why - a
multiply is used for every character in the string.

The following function, called 2^22 times in a loop, times in at 530ms
for 7-character strings.

static long
string_hash1(register char *p, int size)
{
	register int len;
	register long x;

	len = size;
	x = *p << 7;
	while (--len >= 0)
		x = (100003*x) ^ *p++;
	x ^= size;
	return x;
}

Looking around the web I found the following hash function, which is
much faster, and seems to distribute better than the python hash
function.

The following function, called 2^22 times in a loop, times in at 160ms
for 7-character strings.

static long
string_hash3(register char *p, register int size)
{
	register long x;
	register char c;

	x = 0xd2d84a61;
        while (c = *p++)
		x ^= ( (x<<7) + c + (x>>5) );
	return x;
}

I also came up with a hash function of my own, which seems to
distribute near-perfectly (in the sense of being comparable to
assigning, as hashes, random numbers to unique strings) and be faster
yet (at least, on my P4 box).

The following function, called 2^22 times in a loop, times in at 120ms
for 7-character strings.

static long
string_hash6(register unsigned short *p, int size)
{
	register unsigned long x = 0;
       
      if (size==0) return 0;

	len = (size+1) >> 1;
	while (len--) {
		x += (x>>14) + (*p++ * 0xd2d84a61);
		}
	x += (x>>14) + (size*0xd2d84a61);
	
	return x;
}

Ive tested these functions by hashing a large set of strings generated
by instrumenting the python interpeter to emit a string every time a
string is added to a dictionary. These strings are hashed and thrown
into the buckets of various sized tables. I then calculate sigma
statistics (sum((observed-expected)^2)/(N-1)) for the number of items
in the buckets of those tables.

Here are the sum(sigma) results I am getting in my tests:
string_hash1       sum(sigma) ~= 30K
string_hash3       sum(sigma) ~= 23-24K
string_hash6       sum(sigma) ~= 23-34K
string_hashRandom  sum(sigma) ~= 23-24K


Maddeningly, I havent been able to translate these near-perfect
distributions into improvements in pystones.

With the current hash function, pystone does an average of 1.2 probes in
the lookdict_string() function. With either of these "near-perfect" hash
functions, it does at best 1.3 probes (given exhaustive searches for
'good' shift paramaters, though not multipliers).

Im not sure what other tests to try out, or how I might go about
tweaking the hashes to perform better in pystone. Im hoping that someone
on python-dev has some experience in testing hash functions, and can
suggest some additional tests and/or tweaks.



From DavidA@ActiveState.com  Wed Jun 25 01:45:30 2003
From: DavidA@ActiveState.com (David Ascher)
Date: Tue, 24 Jun 2003 17:45:30 -0700
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <m3k7bbz80k.fsf@mira.informatik.hu-berlin.de>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>	<3EF453DE.4040301@lemburg.com>	<m38yrvoa99.fsf@mira.informatik.hu-berlin.de>	<3EF4843E.60901@lemburg.com>	<m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>	<3EF48848.8040707@lemburg.com>	<m3smq1iaev.fsf@mira.informatik.hu-berlin.de>	<3EF6C6CB.2030103@lemburg.com>	<m3isqw1nsy.fsf@mira.informatik.hu-berlin.de>	<3EF801FB.2020309@lemburg.com> <m3k7bbz80k.fsf@mira.informatik.hu-berlin.de>
Message-ID: <3EF8F0AA.8030308@ActiveState.com>

Martin v. ? wrote:

>"M.-A. Lemburg" <mal@lemburg.com> writes:
>
>  
>
>>That's a good hint, but it only works with IDLE and Notepad,
>>doesn't it ? Other editors or Python IDEs will probably need
>>some more time to grow such a feature.
>>    
>>
>
>Correct. However, which other editors are commonly used to teach
>Python?
>

We have educational partners who use Komodo. (That said, Komodo should 
be able to do the right thing regardless).

I'm sure many people use Emacs to teach Python too -- I used to in some 
circles =).

--david



From greg@cosc.canterbury.ac.nz  Wed Jun 25 02:11:18 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Jun 2003 13:11:18 +1200 (NZST)
Subject: [Python-Dev] Patch  595601
In-Reply-To: <LNBBLJKPBEHFEDALKOLCEEJHELAB.tim.one@comcast.net>
Message-ID: <200306250111.h5P1BIj23648@oma.cosc.canterbury.ac.nz>

> Because Python resets a Python file object's stream to NULL when a Python
> file object is closed,

If that's the only problem, then surely it's just a matter of correct
GIL usage? I.e. if a thread using a file object releases the GIL, it
should re-acquire it and check that the FILE * in the file object is
still valid before using it again.

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



From greg@cosc.canterbury.ac.nz  Wed Jun 25 02:17:45 2003
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Jun 2003 13:17:45 +1200 (NZST)
Subject: [Python-Dev] Patch 595601
In-Reply-To: <200306240806.h5O86Rn15730@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <200306250117.h5P1Hjl23666@oma.cosc.canterbury.ac.nz>

> I disagree that the thread has done nothing wrong: if one thread is
> closing a file that another thread is still reading, the whole
> application is buggy

It just seemed it would be a bit neater if the close succeeded and any
subsequent read failed, since that's what would happen anyway if the
close had been done a moment earlier. I guess it doesn't matter all
that much.

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


From tim.one@comcast.net  Wed Jun 25 02:27:05 2003
From: tim.one@comcast.net (Tim Peters)
Date: Tue, 24 Jun 2003 21:27:05 -0400
Subject: [Python-Dev] Patch  595601
In-Reply-To: <200306250111.h5P1BIj23648@oma.cosc.canterbury.ac.nz>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEKOELAB.tim.one@comcast.net>

[Greg Ewing]
> If that's the only problem, then surely it's just a matter of correct
> GIL usage? I.e. if a thread using a file object releases the GIL, it
> should re-acquire it and check that the FILE * in the file object is
> still valid before using it again.

Greg, read the patch comments -- they've been there a long time.  There
would be no problem if Python didn't release the GIL around potentially
blocking I/O calls.  But the instant you release the GIL, you have no
guarantee that f->f_fp won't change to NULL from one nanosecond to the next.
There isn't a simple solution to this.



From nas-python@python.ca  Wed Jun 25 05:26:51 2003
From: nas-python@python.ca (Neil Schemenauer)
Date: Tue, 24 Jun 2003 21:26:51 -0700
Subject: [Python-Dev] Python hash function
In-Reply-To: <001e01c33a94$172753d0$6401a8c0@damien>
References: <001e01c33a94$172753d0$6401a8c0@damien>
Message-ID: <20030625042651.GA32737@glacier.arctrix.com>

Damien Morton wrote:
> Maddeningly, I havent been able to translate these near-perfect
> distributions into improvements in pystones.

No time to look at this in deal but do you know about ob_shash?  I
suspect most strings used by pystone are interned.

  Neil


From martin@v.loewis.de  Wed Jun 25 06:12:16 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 25 Jun 2003 07:12:16 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <3EF8F0AA.8030308@ActiveState.com>
References: <008301c334f3$3dc00ec0$125ffea9@oemcomputer>
 <3EF453DE.4040301@lemburg.com>
 <m38yrvoa99.fsf@mira.informatik.hu-berlin.de>
 <3EF4843E.60901@lemburg.com>
 <m31xxnmmfw.fsf@mira.informatik.hu-berlin.de>
 <3EF48848.8040707@lemburg.com>
 <m3smq1iaev.fsf@mira.informatik.hu-berlin.de>
 <3EF6C6CB.2030103@lemburg.com>
 <m3isqw1nsy.fsf@mira.informatik.hu-berlin.de>
 <3EF801FB.2020309@lemburg.com>
 <m3k7bbz80k.fsf@mira.informatik.hu-berlin.de>
 <3EF8F0AA.8030308@ActiveState.com>
Message-ID: <m3u1aepwpb.fsf@mira.informatik.hu-berlin.de>

David Ascher <DavidA@ActiveState.com> writes:

> We have educational partners who use Komodo. (That said, Komodo should
> be able to do the right thing regardless).
> 
> I'm sure many people use Emacs to teach Python too -- I used to in
> some circles =).

Thanks for the data. I'll try to find out what is needed to make them
work with Python source encodings transparently (for Emacs, it will be
tough, as it does not support UTF-8 signatures all that well).

Regards,
Martin


From dmorton@bitfurnace.com  Wed Jun 25 06:24:23 2003
From: dmorton@bitfurnace.com (damien morton)
Date: Wed, 25 Jun 2003 01:24:23 -0400
Subject: [Python-Dev] Python hash function
In-Reply-To: <20030625042651.GA32737@glacier.arctrix.com>
Message-ID: <002401c33ada$0a62bb30$6401a8c0@damien>

I do know about ob_shash, and youre probably right that most strings
used by pystone are interned. Even so, my running python/pystone through
vtune showed that as much time is spent in string_hash() as
lookdict_string(). Lookdict_string() is, of course, called many more
times than string_hash() - but the total self time for each function is
comparable.

Not only does the current hash function use a multiply for every
character, but it doesn't parralelise very well. The functions I have
been playing with are about 4 times faster than the current function,
while using only half the multiplies, adds and loop iterations.

> -----Original Message-----
> From: Neil Schemenauer [mailto:nas-python@python.ca] 
> Sent: Wednesday, 25 June 2003 00:27
> To: damien.morton@acm.org
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] Python hash function
> 
> 
> Damien Morton wrote:
> > Maddeningly, I havent been able to translate these near-perfect 
> > distributions into improvements in pystones.
> 
> No time to look at this in deal but do you know about 
> ob_shash?  I suspect most strings used by pystone are interned.
> 
>   Neil



From Raymond Hettinger" <python@rcn.com  Wed Jun 25 16:35:14 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Wed, 25 Jun 2003 11:35:14 -0400
Subject: [Python-Dev] Py2.1
Message-ID: <000e01c33b2f$5f74d5e0$125ffea9@oemcomputer>

After closing a bug report for something fixed in Py2.2.3 and beyond,
I later wondered if it should be left open so that a fix can be made back
to Py2.1.4.

My question is whether there is going to be another bugfix release
for 2.1 or can we limit our open bugs and backports to just 2.2? 

My own preference is to avoid considering 2.1 because the issues
and solutions tend to change as you go back in time.


Raymond Hettinger


From fdrake@acm.org  Wed Jun 25 16:46:09 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Wed, 25 Jun 2003 11:46:09 -0400
Subject: [Python-Dev] Py2.1
In-Reply-To: <000e01c33b2f$5f74d5e0$125ffea9@oemcomputer>
References: <000e01c33b2f$5f74d5e0$125ffea9@oemcomputer>
Message-ID: <16121.50113.646383.818003@grendel.zope.com>

Raymond Hettinger writes:
 > After closing a bug report for something fixed in Py2.2.3 and beyond,
 > I later wondered if it should be left open so that a fix can be made back
 > to Py2.1.4.

I'm certainly happy to forget about anything before 2.2.4.  ;-)


  -Fred

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


From aahz@pythoncraft.com  Wed Jun 25 17:16:28 2003
From: aahz@pythoncraft.com (Aahz)
Date: Wed, 25 Jun 2003 12:16:28 -0400
Subject: [Python-Dev] Py2.1
In-Reply-To: <000e01c33b2f$5f74d5e0$125ffea9@oemcomputer>
References: <000e01c33b2f$5f74d5e0$125ffea9@oemcomputer>
Message-ID: <20030625161627.GA24949@panix.com>

On Wed, Jun 25, 2003, Raymond Hettinger wrote:
>
> After closing a bug report for something fixed in Py2.2.3 and beyond,
> I later wondered if it should be left open so that a fix can be made back
> to Py2.1.4.
> 
> My question is whether there is going to be another bugfix release
> for 2.1 or can we limit our open bugs and backports to just 2.2? 

As it says in PEP 6: "In general, only the N-1 release will be under
active maintenance at any time."
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

Usenet is not a democracy.  It is a weird cross between an anarchy and a
dictatorship.  


From Anthony Baxter <anthony@interlink.com.au>  Wed Jun 25 17:22:16 2003
From: Anthony Baxter <anthony@interlink.com.au> (Anthony Baxter)
Date: Thu, 26 Jun 2003 02:22:16 +1000
Subject: [Python-Dev] Py2.1
In-Reply-To: <000e01c33b2f$5f74d5e0$125ffea9@oemcomputer>
Message-ID: <200306251622.h5PGMGi7002985@localhost.localdomain>

>>> "Raymond Hettinger" wrote
> After closing a bug report for something fixed in Py2.2.3 and beyond,
> I later wondered if it should be left open so that a fix can be made back
> to Py2.1.4.
> 
> My question is whether there is going to be another bugfix release
> for 2.1 or can we limit our open bugs and backports to just 2.2? 
> 
> My own preference is to avoid considering 2.1 because the issues
> and solutions tend to change as you go back in time.

My own opinion (as someone who's been down this path before) is that
another 2.1.x release is only worthwhile if a sufficiently vile bug
crops up in a way as to cause serious problems (as the GC and
trashcan bugs did for 2.1.2/2.1.3). At that point, it might be worth
considering any other bugs. At the time of 2.1.2, I trawled back
through months of changelogs for bugs that were nasty enough to merit
fixing. I'm not convinced that this was worth doing, in hindsight. 
Some of the bug fixes I folded back in no doubt made people's life
easier, but most probably won't ever be noticed. At this point in 
Python's life-cycle (there's been 4 2.2 releases now, and we're coming
up on the first 2.3 release), I don't think anyone would expect a
new Py2.1 release unless it was fixing a serious serious problem. 

On the other hand, if you're fixing a bug and you do see a fix that 
could be applied to 2.1, and you're willing to do the (hopefully small) 
amount of work to apply it to the 2.1 branch, more power to you. :)

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



From doko@cs.tu-berlin.de  Wed Jun 25 18:35:15 2003
From: doko@cs.tu-berlin.de (Matthias Klose)
Date: Wed, 25 Jun 2003 19:35:15 +0200
Subject: [Python-Dev] Py2.1
In-Reply-To: <200306251622.h5PGMGi7002985@localhost.localdomain>
References: <000e01c33b2f$5f74d5e0$125ffea9@oemcomputer>
 <200306251622.h5PGMGi7002985@localhost.localdomain>
Message-ID: <16121.56659.30531.555526@gargle.gargle.HOWL>

Anthony Baxter writes:
> 
> >>> "Raymond Hettinger" wrote
> > After closing a bug report for something fixed in Py2.2.3 and beyond,
> > I later wondered if it should be left open so that a fix can be made back
> > to Py2.1.4.
> > 
> > My question is whether there is going to be another bugfix release
> > for 2.1 or can we limit our open bugs and backports to just 2.2? 
> > 
> > My own preference is to avoid considering 2.1 because the issues
> > and solutions tend to change as you go back in time.
> 
> My own opinion (as someone who's been down this path before) is that
> another 2.1.x release is only worthwhile if a sufficiently vile bug
> crops up in a way as to cause serious problems (as the GC and
> trashcan bugs did for 2.1.2/2.1.3).

there is the security related fix for os.py (_execvpe), which is in
CVS, but not in a released 2.1.x. And a major application (zope) still
requires 2.1.x.

	Matthias


From doko@cs.tu-berlin.de  Wed Jun 25 18:49:41 2003
From: doko@cs.tu-berlin.de (Matthias Klose)
Date: Wed, 25 Jun 2003 19:49:41 +0200
Subject: [Python-Dev] deprecate dbm module & add bsddb185 module for 2.2.x
Message-ID: <16121.57525.321181.213083@gargle.gargle.HOWL>

At least on current Debian systems (testing/unstable), the dbm module
cannot be built anymore using the classic ndbm interface. Building
this module using the BSD DB compatibility interface, or the GNU GDBM
compatibility interface, is not an option, because the file format
differs and existing archives cannot be read anymore. I'm unaware of
the situation on other Linux systems and other systems.  Would it be
possible to deprecate the use of the dbm module for 2.3, or is it
still used on many systems?

Would it be acceptable to backport the bsddb185 module to the 2.2
branch?

	Matthias


From doko@cs.tu-berlin.de  Wed Jun 25 18:52:42 2003
From: doko@cs.tu-berlin.de (Matthias Klose)
Date: Wed, 25 Jun 2003 19:52:42 +0200
Subject: [Python-Dev] Re: SF CVS hosed?
In-Reply-To: <B722EABC-A2F9-11D7-B66E-0030655234CE@cwi.nl>
References: <200306200657.h5K6virT011718@localhost.localdomain>
 <B722EABC-A2F9-11D7-B66E-0030655234CE@cwi.nl>
Message-ID: <16121.57706.255147.73062@gargle.gargle.HOWL>

Jack Jansen writes:
> 
> On Friday, Jun 20, 2003, at 08:57 Europe/Amsterdam, Anthony Baxter 
> wrote:
> 
> >
> >>>> Anthony Baxter wrote
> >>
> >> Attempting a cvs up at the moment is failing with:
> >>
> >> cvs server: failed to create lock directory for 
> >> `/cvsroot/python/python/dist/
> > src' (/cvsroot/python/python/dist/src/#cvs.lock): Permission denied
> >> cvs server: failed to obtain dir lock in repository 
> >> `/cvsroot/python/python/d
> > ist/src'
> >> cvs [server aborted]: read lock failed - giving up
> >
> > After quite some time of not working, it of course started working 2 
> > minutes
> > after I sent this email. *sigh*
> 
> It's still (or again?) failing for me...
> Ah, it works again!
> 
> I'll assume its a transient problem for now. If it persists we should 
> file a
> support request later.

I still am not able to complete a checkout/update as an anonymous
user. For the meantime, please could somebody provide snapshots (maybe
weekly) on some site?

Thanks, Matthias


From allison@sumeru.stanford.EDU  Wed Jun 25 19:31:27 2003
From: allison@sumeru.stanford.EDU (Dennis Allison)
Date: Wed, 25 Jun 2003 11:31:27 -0700 (PDT)
Subject: [Python-Dev] Py2.1
In-Reply-To: <200306251622.h5PGMGi7002985@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.10306251129090.27344-100000@sumeru.stanford.EDU>

Another data point:
Currently all Zope systems (2.5.1, 2.6.1)  appear to be constrained to use
Py2.1.3.  

On Thu, 26 Jun 2003, Anthony Baxter wrote:

> 
> >>> "Raymond Hettinger" wrote
> > After closing a bug report for something fixed in Py2.2.3 and beyond,
> > I later wondered if it should be left open so that a fix can be made back
> > to Py2.1.4.
> > 
> > My question is whether there is going to be another bugfix release
> > for 2.1 or can we limit our open bugs and backports to just 2.2? 
> > 
> > My own preference is to avoid considering 2.1 because the issues
> > and solutions tend to change as you go back in time.
> 
> My own opinion (as someone who's been down this path before) is that
> another 2.1.x release is only worthwhile if a sufficiently vile bug
> crops up in a way as to cause serious problems (as the GC and
> trashcan bugs did for 2.1.2/2.1.3). At that point, it might be worth
> considering any other bugs. At the time of 2.1.2, I trawled back
> through months of changelogs for bugs that were nasty enough to merit
> fixing. I'm not convinced that this was worth doing, in hindsight. 
> Some of the bug fixes I folded back in no doubt made people's life
> easier, but most probably won't ever be noticed. At this point in 
> Python's life-cycle (there's been 4 2.2 releases now, and we're coming
> up on the first 2.3 release), I don't think anyone would expect a
> new Py2.1 release unless it was fixing a serious serious problem. 
> 
> On the other hand, if you're fixing a bug and you do see a fix that 
> could be applied to 2.1, and you're willing to do the (hopefully small) 
> amount of work to apply it to the 2.1 branch, more power to you. :)
> 
> Anthony
> -- 
> Anthony Baxter     <anthony@interlink.com.au>   
> It's never too late to have a happy childhood.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> 



From jeremy@zope.com  Wed Jun 25 19:39:01 2003
From: jeremy@zope.com (Jeremy Hylton)
Date: Wed, 25 Jun 2003 14:39:01 -0400
Subject: [Python-Dev] Py2.1
In-Reply-To: <Pine.LNX.4.10.10306251129090.27344-100000@sumeru.stanford.EDU>
Message-ID: <web-1726264@digicool.com>

On Wed, 25 Jun 2003 11:31:27 -0700 (PDT)
 Dennis Allison <allison@sumeru.stanford.EDU> wrote:
> Another data point:
> Currently all Zope systems (2.5.1, 2.6.1)  appear to be
> constrained to use
> Py2.1.3.  

I'm hoping that constraint will go away soon.  Zope 2.7
requires Python 2.2 and Zope 2.6 appears to run fine on
Python 2.2.  I don't know when Zope's official position
will change, but I hope it will be soon.

On the other hand, at least two of the 2.1.x releases were
driven in large part by the need to fix critical-to-Zope
bugs.

Jeremy


From martin@v.loewis.de  Wed Jun 25 21:30:00 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 25 Jun 2003 22:30:00 +0200
Subject: [Python-Dev] deprecate dbm module & add bsddb185 module for 2.2.x
In-Reply-To: <16121.57525.321181.213083@gargle.gargle.HOWL>
References: <16121.57525.321181.213083@gargle.gargle.HOWL>
Message-ID: <m3y8zpx5mf.fsf@mira.informatik.hu-berlin.de>

Matthias Klose <doko@cs.tu-berlin.de> writes:

> Would it be possible to deprecate the use of the dbm module for 2.3,
> or is it still used on many systems?

It works fine on most Unix systems, so I see no reason to deprecate
the module.

Regards,
Martin


From DavidA@ActiveState.com  Wed Jun 25 21:40:34 2003
From: DavidA@ActiveState.com (David Ascher)
Date: Wed, 25 Jun 2003 13:40:34 -0700
Subject: [Python-Dev] OSCON Lightning Talk Proposals still being accepted
Message-ID: <3EFA08C2.8050703@ActiveState.com>

If you're going to OSCON (http://conferences.oreillynet.com/os2003/) and 
want to give a very
short presentation about something Python-related, send me an email.  
Please put the word
"lightning" in the subject line.  The lightning talk session is 
scheduled for Thursday, from 4:30 till 6:00.

We're still accepting proposals, so send one in today!  I'll probably be 
accepting proposals
until late in the game, except if the slot fills up.

If you've never heard of lightning talks, you can find out more 
information at:
    http://perl.plover.com/lt/osc2003/lightning-talks.html

But ignore the submission informations on that site, just send me email.

See you in Portland,

-- David Ascher




From niemeyer@conectiva.com  Thu Jun 26 18:04:56 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Thu, 26 Jun 2003 14:04:56 -0300
Subject: [Python-Dev] Yet more SRE
Message-ID: <20030626170456.GA25685@ibook.distro.conectiva>

I've just submitted to SF #757624 the third implementation of the
SRE changes.

Unlike the other implementations, this one doesn't recurse at all, and
doesn't change the meaning of the opcodes in the engine. Indeed, the
original logic is mostly unchanged, and the recursion has been removed
by a code reorganization. Most of the magic is done using "jumps", and
"context saving" inside SRE_MATCH. It's even possible to reenable the
recursive scheme by enabling the USE_RECURSION macro.

Besides the regression tests, I have tested this using Fredrik's
suggestion, with a 4MB XML file and xmllib/tokenize modules. There
was a very small slow down (i.e. about 37.4s in old implementation
vs. 38.0s in new implementation).

Bugs previously mentioned are also fixed in this implementation.

This implementation also includes the protection against zero-width
match in greedy expressions ("(?=a)*", "a"). Even if this implementation
doesn't get into 2.3, I was thinking about backporting this specific fix
to 2.3. Unfortunately, this would need an additional local variable in
SRE_MATCH of the current implementation, and I'm afraid to reduce the
recursion limit even more by introducing it.

Additionally, after a quick look over perl's regex engine, I also have
some ideas for matching optimization in SRE, but I'll wait a little bit
before fiddling with it.

-- 
Gustavo Niemeyer
http://niemeyer.net


From guido@python.org  Fri Jun 27 11:42:43 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 27 Jun 2003 06:42:43 -0400
Subject: [Python-Dev] Yet more SRE
In-Reply-To: "Your message of Thu, 26 Jun 2003 14:04:56 -0300."
 <20030626170456.GA25685@ibook.distro.conectiva>
References: <20030626170456.GA25685@ibook.distro.conectiva>
Message-ID: <200306271042.h5RAghY21929@pcp02138704pcs.reston01.va.comcast.net>

I have reasons (unfortunately under NDA -- I hope I'll be able to talk
about it soone) for wanting to have a very stable 2.3 out by August
1st.  Experiments with _sre are incompatible with this goal.

I'm trying to get resources to release 2.3b2 on June 30.  Who can
help?

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


From pinard@iro.umontreal.ca  Fri Jun 27 11:54:58 2003
From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois_Pinard?=)
Date: 27 Jun 2003 06:54:58 -0400
Subject: [Python-Dev] Python 2.3b1, distutils and PEP 263
Message-ID: <oqhe6bu6wt.fsf@titan.progiciels-bpi.ca>

Hi, people.

For quite a long time, I noticed that Distutils inserts a supplementary
white line when it transforms the shebang line.  There might be some reason
for this white line, and I'm curious about it.  This does not interact
nicely with PEP 263.  For example, the file:

---------------------------------------------------------------------->
#!/usr/bin/env python
# -*- coding: Latin-1 -*-

"""\
[...]
----------------------------------------------------------------------<

get installed by Distutils as:

---------------------------------------------------------------------->
#!/usr/bin/python

# -*- coding: Latin-1 -*-

"""\
[...]
----------------------------------------------------------------------<

and Python 2.3b1 does not see the `coding:' pragma on the third line.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard


From guido@python.org  Fri Jun 27 12:04:18 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 27 Jun 2003 07:04:18 -0400
Subject: [Python-Dev] Python 2.3b1, distutils and PEP 263
In-Reply-To: "Your message of 27 Jun 2003 06:54:58 EDT."
 <oqhe6bu6wt.fsf@titan.progiciels-bpi.ca>
References: <oqhe6bu6wt.fsf@titan.progiciels-bpi.ca>
Message-ID: <200306271104.h5RB4IB22261@pcp02138704pcs.reston01.va.comcast.net>

> For quite a long time, I noticed that Distutils inserts a supplementary
> white line when it transforms the shebang line.  There might be some reason
> for this white line, and I'm curious about it.  This does not interact
> nicely with PEP 263.  For example, the file:
> 
> ---------------------------------------------------------------------->
> #!/usr/bin/env python
> # -*- coding: Latin-1 -*-
> 
> """\
> [...]
> ----------------------------------------------------------------------<
> 
> get installed by Distutils as:
> 
> ---------------------------------------------------------------------->
> #!/usr/bin/python
> 
> # -*- coding: Latin-1 -*-
> 
> """\
> [...]
> ----------------------------------------------------------------------<
> 
> and Python 2.3b1 does not see the `coding:' pragma on the third line.

This should be easy to fix in CVS.

Who can do it?

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


From skip@pobox.com  Fri Jun 27 12:56:46 2003
From: skip@pobox.com (Skip Montanaro)
Date: Fri, 27 Jun 2003 06:56:46 -0500
Subject: [Python-Dev] Re: Activating `-i' from inside a script?
Message-ID: <16124.12542.188534.731123@montanaro.dyndns.org>

On c.l.py someone asked about forcing a tailend interactive shell from
within the program.  Try Melhase proposed:

    import os

    if __name__ == '__main__':
        discrepancy = True
        if discrepancy:
            os.environ['PYTHONINSPECT'] = "why yes, i'd like that"

but observed that it doesn't work because the environment variable is only
checked at program start.

This change to Modules/main.c makes the above work:

% cvs diff main.c
Index: main.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v
retrieving revision 1.77
diff -c -r1.77 main.c
*** main.c      30 Mar 2003 17:09:58 -0000      1.77
--- main.c      27 Jun 2003 11:50:42 -0000
***************
*** 418,423 ****
--- 418,428 ----
                        filename != NULL, &cf) != 0;
        }
  
+       /* also check at the end in case the program set PYTHONINSPECT */
+       if (!saw_inspect_flag &&
+           (p = Py_GETENV("PYTHONINSPECT")) && *p != '\0')
+               inspect = 1;
+ 
        if (inspect && stdin_is_interactive &&
            (filename != NULL || command != NULL))
                /* XXX */

I can't see that it would affect the functioning of any programs other than
those which set PYTHONINSPECT now.  (But why would they do that and what's
the likelihood such programs exist?)

Any chance this could be squeezed in?  It seems rather elegant:

    try:
        something which fails
    except:
        os.environ["PYTHONINSPECT"] = 1
        raise

(I know we're at beta1, and the programmer could re-run with -i.  But
still...)

Skip



From theller@python.net  Fri Jun 27 13:06:42 2003
From: theller@python.net (Thomas Heller)
Date: Fri, 27 Jun 2003 14:06:42 +0200
Subject: [Python-Dev] Re: Activating `-i' from inside a script?
In-Reply-To: <16124.12542.188534.731123@montanaro.dyndns.org> (Skip
 Montanaro's message of "Fri, 27 Jun 2003 06:56:46 -0500")
References: <16124.12542.188534.731123@montanaro.dyndns.org>
Message-ID: <llvnpvvx.fsf@python.net>

Skip Montanaro <skip@pobox.com> writes:

> On c.l.py someone asked about forcing a tailend interactive shell from
> within the program.  Try Melhase proposed:
>
>     import os
>
>     if __name__ == '__main__':
>         discrepancy = True
>         if discrepancy:
>             os.environ['PYTHONINSPECT'] = "why yes, i'd like that"
>
> but observed that it doesn't work because the environment variable is only
> checked at program start.
>
> This change to Modules/main.c makes the above work:
[...]
>
> Any chance this could be squeezed in?  It seems rather elegant:
>
>     try:
>         something which fails
>     except:
>         os.environ["PYTHONINSPECT"] = 1
>         raise
>
> (I know we're at beta1, and the programmer could re-run with -i.  But
> still...)
>

For a different approach to the same (?) problem see

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65287

Thomas



From tim@zope.com  Fri Jun 27 15:55:02 2003
From: tim@zope.com (Tim Peters)
Date: Fri, 27 Jun 2003 10:55:02 -0400
Subject: [Python-Dev] Yet more SRE
In-Reply-To: <200306271042.h5RAghY21929@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <BIEJKCLHCIOIHAGOKOLHAEHKGBAA.tim@zope.com>

[Guido]
> ...
> I'm trying to get resources to release 2.3b2 on June 30.  Who can
> help?

Barry and I can work on it Sunday (June 29), but not today or Monday.  So we
should shoot for the 29th.



From tim@zope.com  Fri Jun 27 16:39:19 2003
From: tim@zope.com (Tim Peters)
Date: Fri, 27 Jun 2003 11:39:19 -0400
Subject: [Python-Dev] test_copy_reg failing in 2.3 CVS
Message-ID: <BIEJKCLHCIOIHAGOKOLHCEHPGBAA.tim@zope.com>

Here on Win2K:

C:\Code\python\PCbuild>python ../lib/test/test_copy_reg.py
test_bool (__main__.CopyRegTestCase) ... ok
test_class (__main__.CopyRegTestCase) ... ok
test_extension_registry (__main__.CopyRegTestCase) ... ok
test_noncallable_constructor (__main__.CopyRegTestCase) ... FAIL
test_noncallable_reduce (__main__.CopyRegTestCase) ... ok

======================================================================
FAIL: test_noncallable_constructor (__main__.CopyRegTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../lib/test/test_copy_reg.py", line 23, in
test_noncallable_constructor
    type(1), int, "not a callable")
  File "C:\Code\python\lib\unittest.py", line 285, in failUnlessRaises
    raise self.failureException, excName
AssertionError: TypeError

----------------------------------------------------------------------
Ran 5 tests in 0.081s

FAILED (failures=1)
Traceback (most recent call last):
  File "../lib/test/test_copy_reg.py", line 92, in ?
    test_main()
  File "../lib/test/test_copy_reg.py", line 88, in test_main
    test_support.run_unittest(CopyRegTestCase)
  File "C:\Code\python\lib\test\test_support.py", line 259, in run_unittest
    run_suite(suite, testclass)
  File "C:\Code\python\lib\test\test_support.py", line 247, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "../lib/test/test_copy_reg.py", line 23, in
test_noncallable_constructor
    type(1), int, "not a callable")
  File "C:\Code\python\lib\unittest.py", line 285, in failUnlessRaises
    raise self.failureException, excName
AssertionError: TypeError


C:\Code\python\PCbuild>



From jeremy@alum.mit.edu  Fri Jun 27 17:54:44 2003
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: 27 Jun 2003 12:54:44 -0400
Subject: [Python-Dev] test_strptime failed
In-Reply-To: <3EE8FDAE.30605@ocf.berkeley.edu>
References: <1054850175.24597.27.camel@slothrop.zope.com>
 <3EE8FDAE.30605@ocf.berkeley.edu>
Message-ID: <1056732884.25964.4.camel@slothrop.zope.com>

On Thu, 2003-06-12 at 18:24, Brett C. wrote:
> > test test_strptime failed -- Traceback (most recent call last):
> >   File "/home/jeremy/src/python/dist/src/Lib/test/test_strptime.py",
> > line 203, in test_compile
> >     self.failUnless(found, "Matching failed on '%s' using '%s' regex" %
> >   File "/home/jeremy/src/python/dist/src/Lib/unittest.py", line 268, in
> > failUnless
> >     if not expr: raise self.failureException, msg
> > AssertionError: Matching failed on 'Thu 05 Jun 2003 05:46:43 PM EDT'
> > using
> > '(?P<a>Mon|Tue|Wed|Thu|Fri|Sat|Sun)\s*(?P<d>3[0-1]|[1-2]\d|0[1-9]|[1-9]|
> > [1-9])\s*(?P<b>Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s*(?P<Y>\d\d\d\d)\s*(?P<I>1[0-2]|0[1-9]|[1-9]):(?P<M>[0-5]\d|\d):(?P<S>6[0-1]|[0-5]\d|\d)\s*(?P<p>AM|PM)\s*EST' regex
> > 
> 
> Jeremy, are you still getting this failure?  How about anyone else?

Strangely enough, I am.  I've run the tests irregularly over the last
couple of weeks without seeing it.  But today I ran the tests and say
the failure.

Is there any reason you expect that this is a transient bug?

test test_strptime failed -- Traceback (most recent call last):
  File "/home/jeremy/src/python/dist/src/Lib/test/test_strptime.py",
line 203, in test_compile
    self.failUnless(found, "Matching failed on '%s' using '%s' regex" %
  File "/home/jeremy/src/python/dist/src/Lib/unittest.py", line 268, in
failUnless
    if not expr: raise self.failureException, msg
AssertionError: Matching failed on 'Fri 27 Jun 2003 12:49:38 PM EDT'
using
'(?P<a>Mon|Tue|Wed|Thu|Fri|Sat|Sun)\s*(?P<d>3[0-1]|[1-2]\d|0[1-9]|[1-9]|
[1-9])\s*(?P<b>Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s*(?P<Y>\d\d\d\d)\s*(?P<I>1[0-2]|0[1-9]|[1-9]):(?P<M>[0-5]\d|\d):(?P<S>6[0-1]|[0-5]\d|\d)\s*(?P<p>AM|PM)\s*EST' regex

Jeremy




From python@rcn.com  Fri Jun 27 19:11:48 2003
From: python@rcn.com (Raymond Hettinger)
Date: Fri, 27 Jun 2003 14:11:48 -0400
Subject: [Python-Dev] test_strptime failed
References: <1054850175.24597.27.camel@slothrop.zope.com> <3EE8FDAE.30605@ocf.berkeley.edu> <1056732884.25964.4.camel@slothrop.zope.com>
Message-ID: <001d01c33cd7$93d8ccc0$125ffea9@oemcomputer>

> On Thu, 2003-06-12 at 18:24, Brett C. wrote:
> > > test test_strptime failed -- Traceback (most recent call last):
> > >   File "/home/jeremy/src/python/dist/src/Lib/test/test_strptime.py",
> > > line 203, in test_compile
> > >     self.failUnless(found, "Matching failed on '%s' using '%s' regex" %
> > >   File "/home/jeremy/src/python/dist/src/Lib/unittest.py", line 268, in
> > > failUnless
> > >     if not expr: raise self.failureException, msg
> > > AssertionError: Matching failed on 'Thu 05 Jun 2003 05:46:43 PM EDT'
> > > using
> > > '(?P<a>Mon|Tue|Wed|Thu|Fri|Sat|Sun)\s*(?P<d>3[0-1]|[1-2]\d|0[1-9]|[1-9]|
> > >
[1-9])\s*(?P<b>Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s*(?P<Y>\d\d\d\d)\s*(?P<I>1[0-2]|0[1-9]|[1-9]):(?P<M>[0-5]\d|\d):(
?P<S>6[0-1]|[0-5]\d|\d)\s*(?P<p>AM|PM)\s*EST' regex
> > >
> >
> > Jeremy, are you still getting this failure?  How about anyone else?
>
> Strangely enough, I am.  I've run the tests irregularly over the last
> couple of weeks without seeing it.  But today I ran the tests and say
> the failure.

I've run the test hundreds of times and observed no failures on
my WindowsME box.

The traceback above shows the pattern matches through the timezone
and fails on 'EDT' vs 'EST' with the EDT being correct for this time of year.

The EDT version comes from time.strftime().
I suspect the pattern's timezone is extracted from
another source and the difference only shows up
on certain platforms.  This doesn't explain the
transient nature of the bug or what needs to be
changed, but I hope it helps a bit.


Raymond Hettinger


#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################


From niemeyer@conectiva.com  Fri Jun 27 20:05:12 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Fri, 27 Jun 2003 16:05:12 -0300
Subject: [Python-Dev] Python 2.3b1, distutils and PEP 263
In-Reply-To: <200306271104.h5RB4IB22261@pcp02138704pcs.reston01.va.comcast.net>
References: <oqhe6bu6wt.fsf@titan.progiciels-bpi.ca> <200306271104.h5RB4IB22261@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20030627190512.GA1003@ibook.distro.conectiva>

> This should be easy to fix in CVS.
> 
> Who can do it?

I take it, if no one has done so yet.

-- 
Gustavo Niemeyer
http://niemeyer.net


From niemeyer@conectiva.com  Fri Jun 27 20:44:19 2003
From: niemeyer@conectiva.com (Gustavo Niemeyer)
Date: Fri, 27 Jun 2003 16:44:19 -0300
Subject: [Python-Dev] Python 2.3b1, distutils and PEP 263
In-Reply-To: <oqhe6bu6wt.fsf@titan.progiciels-bpi.ca>
References: <oqhe6bu6wt.fsf@titan.progiciels-bpi.ca>
Message-ID: <20030627194419.GB1003@ibook.distro.conectiva>

Hi François!

> For quite a long time, I noticed that Distutils inserts a supplementary
> white line when it transforms the shebang line.  There might be some reason
> for this white line, and I'm curious about it.  This does not interact
> nicely with PEP 263.  For example, the file:
[...]

Just to satisfy your curiosity, it was a bug in the regular expression
matching the first line:

  # check if Python is called on the first line with this expression
  first_line_re = re.compile('^#!.*python[0-9.]*(\s+.*)?$')

The detail here is that \s also matches a newline. Fixed in CVS.

Thanks for reporting!

-- 
Gustavo Niemeyer
http://niemeyer.net


From jeremy@alum.mit.edu  Fri Jun 27 20:55:44 2003
From: jeremy@alum.mit.edu (Jeremy Hylton)
Date: 27 Jun 2003 15:55:44 -0400
Subject: [Python-Dev] socket timeouts and httplib
Message-ID: <1056743743.30075.16.camel@slothrop.zope.com>

There's a long standing, hard to reproduce bug report about httplib --
666219 -- that got me looking at the socket timeout code today.  The
most basic question I have is:  Do we expect the timeout code to work
with the httplib module?  The original timeoutsocket module uses httplib
as an example of its use.

I ask because some simple httplib tests aren't working as expected with
timeouts turned on.  I'm also curious because the socket documentation
says you shouldn't mix timeouts and makefile(), and httplib uses
makefile().

When I do have a small timeout and a slow server, I sometimes see an
error like this:

Traceback (most recent call last):
  File "/tmp/foo.py", line 14, in ?
    f = urllib.urlopen(url)
  File "/home/jeremy/src/python/dist/src/Lib/urllib.py", line 76, in
urlopen
    return opener.open(url)
  File "/home/jeremy/src/python/dist/src/Lib/urllib.py", line 181, in
open
    return getattr(self, name)(url)
  File "/home/jeremy/src/python/dist/src/Lib/urllib.py", line 297, in
open_http
    h.endheaders()
  File "/home/jeremy/src/python/dist/src/Lib/httplib.py", line 710, in
endheaders
    self._send_output()
  File "/home/jeremy/src/python/dist/src/Lib/httplib.py", line 595, in
_send_output
    self.send(msg)
  File "/home/jeremy/src/python/dist/src/Lib/httplib.py", line 562, in
send
    self.connect()
  File "/home/jeremy/src/python/dist/src/Lib/httplib.py", line 546, in
connect
    raise socket.error, msg
IOError: [Errno socket error] (114, 'Operation already in progress')

The socketmodule code is specifically looking for an EINPROGRESS return
from connect(), but I'm getting an EALREADY.  These are related but
distinct errors on Linux.

I'm not sure if I should file a bug report for code or documentation or
if it should somehow be obvious that I'm doing something wrong.

Jeremy




From skip@pobox.com  Fri Jun 27 21:18:07 2003
From: skip@pobox.com (Skip Montanaro)
Date: Fri, 27 Jun 2003 15:18:07 -0500
Subject: [Python-Dev] socket timeouts and httplib
In-Reply-To: <1056743743.30075.16.camel@slothrop.zope.com>
References: <1056743743.30075.16.camel@slothrop.zope.com>
Message-ID: <16124.42623.274216.30459@montanaro.dyndns.org>

    Jeremy> I ask because some simple httplib tests aren't working as
    Jeremy> expected with timeouts turned on.  I'm also curious because the
    Jeremy> socket documentation says you shouldn't mix timeouts and
    Jeremy> makefile(), and httplib uses makefile().

In theory, the change I made to socket.py a couple months ago to always use
its _socketobject (and thus _fileobject) class should allow timeouts to be
used with makefile.  I'd like to know if (and why) you're apparently not
getting that code.

    Jeremy> When I do have a small timeout and a slow server, I sometimes see an
    Jeremy> error like this:

    ...

    Jeremy>     self.connect()
    Jeremy>   File "/home/jeremy/src/python/dist/src/Lib/httplib.py", line 546, in connect
    Jeremy>     raise socket.error, msg
    Jeremy> IOError: [Errno socket error] (114, 'Operation already in progress')

Do you perhaps need to cvs up?  (Or have you modified your copy of
httplib.py?)  I'm cvs up'd and line 546 is the "def close" line two lines
after the above raise statement.

Skip


From dave@boost-consulting.com  Fri Jun 27 21:54:26 2003
From: dave@boost-consulting.com (David Abrahams)
Date: Fri, 27 Jun 2003 16:54:26 -0400
Subject: [Python-Dev] Embedding Python, threading and scalability
Message-ID: <u4r2bs0l9.fsf@boost-consulting.com>

Sorry to intrude here with this, but I fear this guy's question isn't
going to get addressed well on the C++-sig or on python-list, so I was
wondering if someone here, who knows, would mind answering him:

  http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1687739

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From aahz@pythoncraft.com  Fri Jun 27 22:21:09 2003
From: aahz@pythoncraft.com (Aahz)
Date: Fri, 27 Jun 2003 17:21:09 -0400
Subject: [Python-Dev] Embedding Python, threading and scalability
In-Reply-To: <u4r2bs0l9.fsf@boost-consulting.com>
References: <u4r2bs0l9.fsf@boost-consulting.com>
Message-ID: <20030627212109.GA17390@panix.com>

On Fri, Jun 27, 2003, David Abrahams wrote:
> 
> Sorry to intrude here with this, but I fear this guy's question isn't
> going to get addressed well on the C++-sig or on python-list, so I was
> wondering if someone here, who knows, would mind answering him:
> 
>   http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1687739

Actually, comp.lang.python would be perfect, from what I see.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

Usenet is not a democracy.  It is a weird cross between an anarchy and a
dictatorship.  


From eric@enthought.com  Fri Jun 27 23:08:02 2003
From: eric@enthought.com (eric jones)
Date: Fri, 27 Jun 2003 17:08:02 -0500
Subject: [Python-Dev] [ANN] SciPy '03 -- The 2nd Annual Python for Scientific Computing Workshop
Message-ID: <015701c33cf8$96be3670$8901a8c0@ERICDESKTOP>

Hey folks,

I've been postponing this announcement because the registration page
isn't active yet.  It's getting late though, and I thought I'd at least
let you know SciPy '03 is happening.  I'll repost when registration is
open.

Thanks,
Eric

-------------------------------------------------------
SciPy '03
The 2nd Annual Python for Scientific Computing Workshop
-------------------------------------------------------

CalTech, Pasadena, CA
September 11-12, 2003

http://www.scipy.org/site_content/scipy03

This workshop provides a unique opportunity to learn and affect what is
happening in the realm of scientific computing with Python. Attendees
will have the opportunity to review the available tools and how they
apply to specific problems. By providing a forum for developers to share
their Python expertise with the wider industrial, academic, and research
communities, this workshop will foster collaboration and facilitate the
sharing of software components, techniques and a vision for high level
language use in scientific computing.

The cost of the workshop is $100.00 and includes 2 breakfasts and 2
lunches on Sept. 11th and 12th, one dinner on Sept. 11th, and snacks
during breaks.  Online registration is not available yet, but will be
soon.

We would like to have a wide variety of presenters this year.  If you
have a paper you would like to present, please contact
eric@enthought.com.

Discussion about the conference may be directed to the SciPy-user
mailing list:

Mailing list page:     http://www.scipy.org/MailList
Mailinbg list address: scipy-user@scipy.org

Please forward this announcement to anyone/list that might be
interested.


-------------
Co-Hosted By:
-------------

The National Biomedical Computation Resource (NBCR, SDSC, San Diego, CA)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://nbcr.sdsc.edu
The mission of the National Biomedical Computation Resource at the San
Diego
Supercomputer Center is to conduct, catalyze, and enable biomedical
research by harnessing advanced computational technology.


The Center for Advanced Computing Research (CACR, CalTech, Pasadena, CA)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://nbcr.sdsc.edu
CACR is dedicated to the pursuit of excellence in the field of
high-performance computing, communication, and data engineering. Major
activities include carrying out large-scale scientific and engineering
applications on parallel supercomputers and coordinating collaborative
research projects on high-speed network technologies, distributed
computing and database methodologies, and related topics. Our goal is to
help further the state of the art in scientific computing.


Enthought, Inc. (Austin, TX)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://enthought.com
Enthought, Inc. provides scientific and business computing solutions
through software development, consulting and training.


----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701 






From pinard@iro.umontreal.ca  Fri Jun 27 23:56:29 2003
From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois_Pinard?=)
Date: 27 Jun 2003 18:56:29 -0400
Subject: [Python-Dev] Re: Python 2.3b1, distutils and PEP 263
In-Reply-To: <20030627194419.GB1003@ibook.distro.conectiva>
References: <oqhe6bu6wt.fsf@titan.progiciels-bpi.ca>
 <20030627194419.GB1003@ibook.distro.conectiva>
Message-ID: <oqbrwjqgde.fsf@titan.progiciels-bpi.ca>

[Gustavo Niemeyer]

> Just to satisfy your curiosity, it was a bug in the regular expression
> matching the first line: [...]

So, it was not intended, and indeed a bug.  Thanks for your work on this.

> Thanks for reporting!

Special thanks for not throwing bug trackers after me! :-)

P.S. - I would likely report a lot of tiny nits if I was not so afraid of
these beasts.  I perceive bug trackers as guardian monsters, lost from the
entrance of hell, meant to protect maintainers from users like me... :-)

P.P.S. - Any Roundup progress?  I read that it has a nice email interface,
but short of having ever tried it, do not know if this is true.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard


From aahz@pythoncraft.com  Sat Jun 28 00:06:58 2003
From: aahz@pythoncraft.com (Aahz)
Date: Fri, 27 Jun 2003 19:06:58 -0400
Subject: [Python-Dev] Roundup status
In-Reply-To: <oqbrwjqgde.fsf@titan.progiciels-bpi.ca>
References: <oqhe6bu6wt.fsf@titan.progiciels-bpi.ca> <20030627194419.GB1003@ibook.distro.conectiva> <oqbrwjqgde.fsf@titan.progiciels-bpi.ca>
Message-ID: <20030627230658.GA15432@panix.com>

On Fri, Jun 27, 2003, Fran=E7ois Pinard wrote:
>
> P.P.S. - Any Roundup progress?  I read that it has a nice email interfa=
ce,
> but short of having ever tried it, do not know if this is true.

No, it's currently sitting on my plate to give Roundup a beta for
python.org maintenance.  My fault.
--=20
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.=
com/

Usenet is not a democracy.  It is a weird cross between an anarchy and a
dictatorship. =20


From jacobs@penguin.theopalgroup.com  Sat Jun 28 01:01:45 2003
From: jacobs@penguin.theopalgroup.com (Kevin Jacobs)
Date: Fri, 27 Jun 2003 20:01:45 -0400 (EDT)
Subject: [Python-Dev] socket timeouts and httplib
In-Reply-To: <1056743743.30075.16.camel@slothrop.zope.com>
Message-ID: <Pine.LNX.4.44.0306271953030.17971-100000@penguin.theopalgroup.com>

On 27 Jun 2003, Jeremy Hylton wrote:
> There's a long standing, hard to reproduce bug report about httplib --
> 666219 -- that got me looking at the socket timeout code today.  The
> most basic question I have is:  Do we expect the timeout code to work
> with the httplib module?  The original timeoutsocket module uses httplib
> as an example of its use.

I know for a fact that httplib is currently broken with regard to timeouts
and keyboard interrupts on SSL sockets, and wouldn't be at all surprised if
it was for normal transfers too.  As for the error you are seeing, EALREADY
is usually the result of two calls to connect() that are racing each other.
Finding out why it is being called twice will likely lead to an obvious
solution.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com



From kiko@async.com.br  Sat Jun 28 18:53:46 2003
From: kiko@async.com.br (Christian Reis)
Date: Sat, 28 Jun 2003 14:53:46 -0300
Subject: [Python-Dev] Bug with ExtensionClass and __coerce__
Message-ID: <20030628175346.GC3110@async.com.br>

In the next chapter of the war for Persistent.__cmp__, I found a bug in
ExtensionClass's handling of __coerce__. Here's a paired-down testcase.

    from ExtensionClass import Base

    class Foo(Base):
        def __coerce__(self, other): return None

    class Bar(Base):
        def __coerce__(self, other): return NotImplemented

    f = Foo(); assert 0 < f

        -> SystemError: error return without exception set

    b = Bar(); assert 0 < b

        -> SystemError: new style getargs format but argument is not a tuple

As far as I know (and the PSL docs say) these are the only valid ways to
give up __coerce__. Guido has in the past provided a hint to the latter
error:

http://mail.zope.org/pipermail/zope-coders/2002-January/000594.html

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL


From Jack.Jansen@cwi.nl  Sat Jun 28 21:25:00 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Sat, 28 Jun 2003 22:25:00 +0200
Subject: 2.3b2 this weekend (was Re: [Python-Dev] Yet more SRE)
In-Reply-To: <BIEJKCLHCIOIHAGOKOLHAEHKGBAA.tim@zope.com>
Message-ID: <9765B5DE-A9A6-11D7-B88D-000A27B19B96@cwi.nl>

On vrijdag, jun 27, 2003, at 16:55 Europe/Amsterdam, Tim Peters wrote:

> [Guido]
>> ...
>> I'm trying to get resources to release 2.3b2 on June 30.  Who can
>> help?
>
> Barry and I can work on it Sunday (June 29), but not today or Monday.  
> So we
> should shoot for the 29th.

I can help tonight and tomorrownight (i.e. saturday and sunday, MET). I 
might be able to put in some time on monday, but this is unsure.

I will start with bug 762147, and (if Barry or someone else from Python 
Labs can give me the okay for a location somewhere on www.python.org) 
762150.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From barry@python.org  Sat Jun 28 21:59:56 2003
From: barry@python.org (Barry Warsaw)
Date: 28 Jun 2003 16:59:56 -0400
Subject: 2.3b2 this weekend (was Re: [Python-Dev] Yet more SRE)
In-Reply-To: <9765B5DE-A9A6-11D7-B88D-000A27B19B96@cwi.nl>
References: <9765B5DE-A9A6-11D7-B88D-000A27B19B96@cwi.nl>
Message-ID: <1056833996.6280.44.camel@anthem>

On Sat, 2003-06-28 at 16:25, Jack Jansen wrote:

> I will start with bug 762147, and (if Barry or someone else from Python 
> Labs can give me the okay for a location somewhere on www.python.org) 
> 762150.

Jack, did you see my pvt reply on this from last night?

Once again, I have a gig tonight (Cravin' Dogs CD release party
<shameless plug> :), but I'll be available most of the day tomorrow.
I can't do the python.org twiddling until then.

I suggest that folks coordinating on the Python release meet up on
irc.freenode.net #python-dev.  I haven't talked to Tim yet, but expect a
cvs freeze tomorrow -- let's say by 12:00 noon EDT.

-Barry




From guido@python.org  Sat Jun 28 22:40:11 2003
From: guido@python.org (Guido van Rossum)
Date: Sat, 28 Jun 2003 17:40:11 -0400
Subject: [Python-Dev] Re: Activating `-i' from inside a script?
In-Reply-To: "Your message of Fri, 27 Jun 2003 06:56:46 CDT."
 <16124.12542.188534.731123@montanaro.dyndns.org>
References: <16124.12542.188534.731123@montanaro.dyndns.org>
Message-ID: <200306282140.h5SLeBt24770@pcp02138704pcs.reston01.va.comcast.net>

> On c.l.py someone asked about forcing a tailend interactive shell from
> within the program.  Try Melhase proposed:
> 
>     import os
> 
>     if __name__ == '__main__':
>         discrepancy = True
>         if discrepancy:
>             os.environ['PYTHONINSPECT'] = "why yes, i'd like that"
> 
> but observed that it doesn't work because the environment variable is only
> checked at program start.
> 
> This change to Modules/main.c makes the above work:
> 
> % cvs diff main.c
> Index: main.c
> ===================================================================
> RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v
> retrieving revision 1.77
> diff -c -r1.77 main.c
> *** main.c      30 Mar 2003 17:09:58 -0000      1.77
> --- main.c      27 Jun 2003 11:50:42 -0000
> ***************
> *** 418,423 ****
> --- 418,428 ----
>                         filename != NULL, &cf) != 0;
>         }
>   
> +       /* also check at the end in case the program set PYTHONINSPECT */
> +       if (!saw_inspect_flag &&
> +           (p = Py_GETENV("PYTHONINSPECT")) && *p != '\0')
> +               inspect = 1;
> + 
>         if (inspect && stdin_is_interactive &&
>             (filename != NULL || command != NULL))
>                 /* XXX */
> 
> I can't see that it would affect the functioning of any programs other than
> those which set PYTHONINSPECT now.  (But why would they do that and what's
> the likelihood such programs exist?)
> 
> Any chance this could be squeezed in?  It seems rather elegant:
> 
>     try:
>         something which fails
>     except:
>         os.environ["PYTHONINSPECT"] = 1
>         raise
> 
> (I know we're at beta1, and the programmer could re-run with -i.  But
> still...)

Looks harmless to me.  Thomas Heller's alternative really does
something different.  Skip can check it in.

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


From guido@python.org  Sat Jun 28 22:41:14 2003
From: guido@python.org (Guido van Rossum)
Date: Sat, 28 Jun 2003 17:41:14 -0400
Subject: [Python-Dev] proposed Tkinter change; any likelihood of acceptance?
In-Reply-To: "Your message of Tue, 24 Jun 2003 11:49:07 PDT."
 <rowen-71B780.11490724062003@main.gmane.org>
References: <rowen-71B780.11490724062003@main.gmane.org>
Message-ID: <200306282141.h5SLfEq24782@pcp02138704pcs.reston01.va.comcast.net>

> The primary change is to add a "name" argument to the Variable.__init__, 
> bringing it in line with other Tkinter classes. The justification is to 
> allow users to create new Tkinter variables that point to existing tcl 
> variables (e.g. somewhat similar to nametowidget). In some cases this 
> may be more convenient than using setvar and getvar.

I haven't seen any other responses to this; I propose that it's too
late for 2.3b2 given that it's a feature change with somewhat unclear
consequences.  For 2.3.1 or 2.4 I'd be okay.

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


From guido@python.org  Sat Jun 28 22:42:29 2003
From: guido@python.org (Guido van Rossum)
Date: Sat, 28 Jun 2003 17:42:29 -0400
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: "Your message of Tue, 17 Jun 2003 15:18:07 EDT."
 <Pine.LNX.4.44.0306171515380.2886-100000@penguin.theopalgroup.com>
References: <Pine.LNX.4.44.0306171515380.2886-100000@penguin.theopalgroup.com>
Message-ID: <200306282142.h5SLgTX24798@pcp02138704pcs.reston01.va.comcast.net>

[Kevin Jacobs, privately]
> I'll vote for applying patch #751916, which fixes some memory leaks in the
> timeout code, and allows the SSL code to recover from keyboard interrupts.
> I have several applications that work with 2.2.x that do not currently with
> the 2.3 CVS due to this issue.

Can someone review this and apply if it's okay?  From this description
I'd be okay with including it, but I have no time to review.

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


From guido@python.org  Sat Jun 28 22:43:08 2003
From: guido@python.org (Guido van Rossum)
Date: Sat, 28 Jun 2003 17:43:08 -0400
Subject: [Python-Dev] Yet more SRE
In-Reply-To: "Your message of Fri, 27 Jun 2003 10:55:02 EDT."
 <BIEJKCLHCIOIHAGOKOLHAEHKGBAA.tim@zope.com>
References: <BIEJKCLHCIOIHAGOKOLHAEHKGBAA.tim@zope.com>
Message-ID: <200306282143.h5SLh8Z24819@pcp02138704pcs.reston01.va.comcast.net>

> [Guido]
> > ...
> > I'm trying to get resources to release 2.3b2 on June 30.  Who can
> > help?
> 
> Barry and I can work on it Sunday (June 29), but not today or
> Monday.  So we should shoot for the 29th.

OK, let's do it Sunday the 29th.

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


From guido@python.org  Sat Jun 28 22:51:26 2003
From: guido@python.org (Guido van Rossum)
Date: Sat, 28 Jun 2003 17:51:26 -0400
Subject: [Python-Dev] socket timeouts and httplib
In-Reply-To: "Your message of 27 Jun 2003 15:55:44 EDT."
 <1056743743.30075.16.camel@slothrop.zope.com>
References: <1056743743.30075.16.camel@slothrop.zope.com>
Message-ID: <200306282151.h5SLpQN24876@pcp02138704pcs.reston01.va.comcast.net>

> When I do have a small timeout and a slow server, I sometimes see an
> error like this:
[...]
> IOError: [Errno socket error] (114, 'Operation already in progress')

Could it be that, while the error isn't perfect, this just means that
the socket timed out?  After all you did say you had a small timeout
and a slow server.  Wouldn't you expect it to fail?

Could you try this again with this patch by Bob Halley?  It's been
proposed as a fix for SF 758239 and while a bit long seems to address
the issue by making timeouts a separate exception.  I hope that it can
go into 2.3b2 tonight.

Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.268
diff -c -r1.268 socketmodule.c
*** socketmodule.c	10 May 2003 07:36:55 -0000	1.268
--- socketmodule.c	25 Jun 2003 04:39:10 -0000
***************
*** 328,333 ****
--- 328,334 ----
  static PyObject *socket_error;
  static PyObject *socket_herror;
  static PyObject *socket_gaierror;
+ static PyObject *socket_timeout;
  
  #ifdef RISCOS
  /* Global variable which is !=0 if Python is running in a RISC OS taskwindow */
***************
*** 575,595 ****
  
  /* Do a select() on the socket, if necessary (sock_timeout > 0).
     The argument writing indicates the direction.
!    This does not raise an exception or return a success indicator;
!    we'll let the actual socket call do that. */
! static void
  internal_select(PySocketSockObject *s, int writing)
  {
  	fd_set fds;
  	struct timeval tv;
  
  	/* Nothing to do unless we're in timeout mode (not non-blocking) */
  	if (s->sock_timeout <= 0.0)
! 		return;
  
  	/* Guard against closed socket */
  	if (s->sock_fd < 0)
! 		return;
  
  	/* Construct the arguments to select */
  	tv.tv_sec = (int)s->sock_timeout;
--- 576,598 ----
  
  /* Do a select() on the socket, if necessary (sock_timeout > 0).
     The argument writing indicates the direction.
!    This does not raise an exception; we'll let our caller do that
!    after they've reacquired the interpreter lock.
!    Returns 1 on timeout, 0 otherwise. */
! static int
  internal_select(PySocketSockObject *s, int writing)
  {
  	fd_set fds;
  	struct timeval tv;
+ 	int n;
  
  	/* Nothing to do unless we're in timeout mode (not non-blocking) */
  	if (s->sock_timeout <= 0.0)
! 		return 0;
  
  	/* Guard against closed socket */
  	if (s->sock_fd < 0)
! 		return 0;
  
  	/* Construct the arguments to select */
  	tv.tv_sec = (int)s->sock_timeout;
***************
*** 599,607 ****
  
  	/* See if the socket is ready */
  	if (writing)
! 		select(s->sock_fd+1, NULL, &fds, NULL, &tv);
  	else
! 		select(s->sock_fd+1, &fds, NULL, NULL, &tv);
  }
  
  /* Initialize a new socket object. */
--- 602,613 ----
  
  	/* See if the socket is ready */
  	if (writing)
! 		n = select(s->sock_fd+1, NULL, &fds, NULL, &tv);
  	else
! 		n = select(s->sock_fd+1, &fds, NULL, NULL, &tv);
! 	if (n == 0)
! 		return 1;
! 	return 0;
  }
  
  /* Initialize a new socket object. */
***************
*** 1090,1105 ****
  	PyObject *sock = NULL;
  	PyObject *addr = NULL;
  	PyObject *res = NULL;
  
  	if (!getsockaddrlen(s, &addrlen))
  		return NULL;
  	memset(addrbuf, 0, addrlen);
  
  	Py_BEGIN_ALLOW_THREADS
! 	internal_select(s, 0);
! 	newfd = accept(s->sock_fd, (struct sockaddr *) addrbuf, &addrlen);
  	Py_END_ALLOW_THREADS
  
  #ifdef MS_WINDOWS
  	if (newfd == INVALID_SOCKET)
  #else
--- 1096,1125 ----
  	PyObject *sock = NULL;
  	PyObject *addr = NULL;
  	PyObject *res = NULL;
+ 	int timeout;
  
  	if (!getsockaddrlen(s, &addrlen))
  		return NULL;
  	memset(addrbuf, 0, addrlen);
  
+ #ifdef MS_WINDOWS
+ 	newfd = INVALID_SOCKET;
+ #else
+ 	newfd = -1;
+ #endif
+ 
  	Py_BEGIN_ALLOW_THREADS
! 	timeout = internal_select(s, 0);
! 	if (!timeout)
! 		newfd = accept(s->sock_fd, (struct sockaddr *) addrbuf,
! 			       &addrlen);
  	Py_END_ALLOW_THREADS
  
+ 	if (timeout) {
+ 		PyErr_SetString(socket_timeout, "timed out");
+ 		return NULL;
+ 	}
+ 
  #ifdef MS_WINDOWS
  	if (newfd == INVALID_SOCKET)
  #else
***************
*** 1405,1414 ****
  Close the socket.  It cannot be used after this call.");
  
  static int
! internal_connect(PySocketSockObject *s, struct sockaddr *addr, int addrlen)
  {
! 	int res;
  
  	res = connect(s->sock_fd, addr, addrlen);
  
  #ifdef MS_WINDOWS
--- 1425,1436 ----
  Close the socket.  It cannot be used after this call.");
  
  static int
! internal_connect(PySocketSockObject *s, struct sockaddr *addr, int addrlen,
! 		 int *timeoutp)
  {
! 	int res, timeout;
  
+ 	timeout = 0;
  	res = connect(s->sock_fd, addr, addrlen);
  
  #ifdef MS_WINDOWS
***************
*** 1423,1431 ****
  			FD_ZERO(&fds);
  			FD_SET(s->sock_fd, &fds);
  			res = select(s->sock_fd+1, NULL, &fds, NULL, &tv);
! 			if (res == 0)
  				res = WSAEWOULDBLOCK;
! 			else if (res > 0)
  				res = 0;
  			/* else if (res < 0) an error occurred */
  		}
--- 1445,1454 ----
  			FD_ZERO(&fds);
  			FD_SET(s->sock_fd, &fds);
  			res = select(s->sock_fd+1, NULL, &fds, NULL, &tv);
! 			if (res == 0) {
  				res = WSAEWOULDBLOCK;
! 				timeout = 1;
! 			} else if (res > 0)
  				res = 0;
  			/* else if (res < 0) an error occurred */
  		}
***************
*** 1438,1444 ****
  
  	if (s->sock_timeout > 0.0) {
  		if (res < 0 && errno == EINPROGRESS) {
! 			internal_select(s, 1);
  			res = connect(s->sock_fd, addr, addrlen);
  			if (res < 0 && errno == EISCONN)
  				res = 0;
--- 1461,1467 ----
  
  	if (s->sock_timeout > 0.0) {
  		if (res < 0 && errno == EINPROGRESS) {
! 			timeout = internal_select(s, 1);
  			res = connect(s->sock_fd, addr, addrlen);
  			if (res < 0 && errno == EISCONN)
  				res = 0;
***************
*** 1449,1454 ****
--- 1472,1478 ----
  		res = errno;
  
  #endif
+ 	*timeoutp = timeout;
  
  	return res;
  }
***************
*** 1461,1474 ****
  	struct sockaddr *addr;
  	int addrlen;
  	int res;
  
  	if (!getsockaddrarg(s, addro, &addr, &addrlen))
  		return NULL;
  
  	Py_BEGIN_ALLOW_THREADS
! 	res = internal_connect(s, addr, addrlen);
  	Py_END_ALLOW_THREADS
  
  	if (res != 0)
  		return s->errorhandler();
  	Py_INCREF(Py_None);
--- 1485,1503 ----
  	struct sockaddr *addr;
  	int addrlen;
  	int res;
+ 	int timeout;
  
  	if (!getsockaddrarg(s, addro, &addr, &addrlen))
  		return NULL;
  
  	Py_BEGIN_ALLOW_THREADS
! 	res = internal_connect(s, addr, addrlen, &timeout);
  	Py_END_ALLOW_THREADS
  
+ 	if (timeout) {
+ 		PyErr_SetString(socket_timeout, "timed out");
+ 		return NULL;
+ 	}
  	if (res != 0)
  		return s->errorhandler();
  	Py_INCREF(Py_None);
***************
*** 1490,1501 ****
  	struct sockaddr *addr;
  	int addrlen;
  	int res;
  
  	if (!getsockaddrarg(s, addro, &addr, &addrlen))
  		return NULL;
  
  	Py_BEGIN_ALLOW_THREADS
! 	res = internal_connect(s, addr, addrlen);
  	Py_END_ALLOW_THREADS
  
  	return PyInt_FromLong((long) res);
--- 1519,1531 ----
  	struct sockaddr *addr;
  	int addrlen;
  	int res;
+ 	int timeout;
  
  	if (!getsockaddrarg(s, addro, &addr, &addrlen))
  		return NULL;
  
  	Py_BEGIN_ALLOW_THREADS
! 	res = internal_connect(s, addr, addrlen, &timeout);
  	Py_END_ALLOW_THREADS
  
  	return PyInt_FromLong((long) res);
***************
*** 1716,1722 ****
  static PyObject *
  sock_recv(PySocketSockObject *s, PyObject *args)
  {
! 	int len, n, flags = 0;
  	PyObject *buf;
  #ifdef __VMS
  	int read_length;
--- 1746,1752 ----
  static PyObject *
  sock_recv(PySocketSockObject *s, PyObject *args)
  {
! 	int len, n = 0, flags = 0, timeout;
  	PyObject *buf;
  #ifdef __VMS
  	int read_length;
***************
*** 1738,1747 ****
  
  #ifndef __VMS
  	Py_BEGIN_ALLOW_THREADS
! 	internal_select(s, 0);
! 	n = recv(s->sock_fd, PyString_AS_STRING(buf), len, flags);
  	Py_END_ALLOW_THREADS
  
  	if (n < 0) {
  		Py_DECREF(buf);
  		return s->errorhandler();
--- 1768,1783 ----
  
  #ifndef __VMS
  	Py_BEGIN_ALLOW_THREADS
! 	timeout = internal_select(s, 0);
! 	if (!timeout)
! 		n = recv(s->sock_fd, PyString_AS_STRING(buf), len, flags);
  	Py_END_ALLOW_THREADS
  
+ 	if (timeout) {
+ 		Py_DECREF(buf);
+ 		PyErr_SetString(socket_timeout, "timed out");
+ 		return NULL;
+ 	}
  	if (n < 0) {
  		Py_DECREF(buf);
  		return s->errorhandler();
***************
*** 1763,1772 ****
  		}
  
  		Py_BEGIN_ALLOW_THREADS
!  	  	internal_select(s, 0);
! 		n = recv(s->sock_fd, read_buf, segment, flags);
  		Py_END_ALLOW_THREADS
  
  		if (n < 0) {
  			Py_DECREF(buf);
  			return s->errorhandler();
--- 1799,1814 ----
  		}
  
  		Py_BEGIN_ALLOW_THREADS
! 		timeout = internal_select(s, 0);
! 		if (!timeout)
! 			n = recv(s->sock_fd, read_buf, segment, flags);
  		Py_END_ALLOW_THREADS
  
+ 		if (timeout) {
+ 			Py_DECREF(buf);
+ 			PyErr_SetString(socket_timeout, "timed out");
+ 			return NULL;
+ 		}
  		if (n < 0) {
  			Py_DECREF(buf);
  			return s->errorhandler();
***************
*** 1805,1811 ****
  	PyObject *buf = NULL;
  	PyObject *addr = NULL;
  	PyObject *ret = NULL;
! 	int len, n, flags = 0;
  	socklen_t addrlen;
  
  	if (!PyArg_ParseTuple(args, "i|i:recvfrom", &len, &flags))
--- 1847,1853 ----
  	PyObject *buf = NULL;
  	PyObject *addr = NULL;
  	PyObject *ret = NULL;
! 	int len, n = 0, flags = 0, timeout;
  	socklen_t addrlen;
  
  	if (!PyArg_ParseTuple(args, "i|i:recvfrom", &len, &flags))
***************
*** 1819,1838 ****
  
  	Py_BEGIN_ALLOW_THREADS
  	memset(addrbuf, 0, addrlen);
! 	internal_select(s, 0);
! 	n = recvfrom(s->sock_fd, PyString_AS_STRING(buf), len, flags,
  #ifndef MS_WINDOWS
  #if defined(PYOS_OS2) && !defined(PYCC_GCC)
! 		     (struct sockaddr *)addrbuf, &addrlen
  #else
! 		     (void *)addrbuf, &addrlen
  #endif
  #else
! 		     (struct sockaddr *)addrbuf, &addrlen
  #endif
! 		     );
  	Py_END_ALLOW_THREADS
  
  	if (n < 0) {
  		Py_DECREF(buf);
  		return s->errorhandler();
--- 1861,1886 ----
  
  	Py_BEGIN_ALLOW_THREADS
  	memset(addrbuf, 0, addrlen);
! 	timeout = internal_select(s, 0);
! 	if (!timeout)
! 		n = recvfrom(s->sock_fd, PyString_AS_STRING(buf), len, flags,
  #ifndef MS_WINDOWS
  #if defined(PYOS_OS2) && !defined(PYCC_GCC)
! 			     (struct sockaddr *)addrbuf, &addrlen
  #else
! 			     (void *)addrbuf, &addrlen
  #endif
  #else
! 			     (struct sockaddr *)addrbuf, &addrlen
  #endif
! 			);
  	Py_END_ALLOW_THREADS
  
+ 	if (timeout) {
+ 		Py_DECREF(buf);
+ 		PyErr_SetString(socket_timeout, "timed out");
+ 		return NULL;
+ 	}
  	if (n < 0) {
  		Py_DECREF(buf);
  		return s->errorhandler();
***************
*** 1864,1870 ****
  sock_send(PySocketSockObject *s, PyObject *args)
  {
  	char *buf;
! 	int len, n, flags = 0;
  #ifdef __VMS
  	int send_length;
  #endif
--- 1912,1918 ----
  sock_send(PySocketSockObject *s, PyObject *args)
  {
  	char *buf;
! 	int len, n = 0, flags = 0, timeout;
  #ifdef __VMS
  	int send_length;
  #endif
***************
*** 1874,1883 ****
  
  #ifndef __VMS
  	Py_BEGIN_ALLOW_THREADS
! 	internal_select(s, 1);
! 	n = send(s->sock_fd, buf, len, flags);
  	Py_END_ALLOW_THREADS
  
  	if (n < 0)
  		return s->errorhandler();
  #else
--- 1922,1936 ----
  
  #ifndef __VMS
  	Py_BEGIN_ALLOW_THREADS
! 	timeout = internal_select(s, 1);
! 	if (!timeout)
! 		n = send(s->sock_fd, buf, len, flags);
  	Py_END_ALLOW_THREADS
  
+ 	if (timeout) {
+ 		PyErr_SetString(socket_timeout, "timed out");
+ 		return NULL;
+ 	}
  	if (n < 0)
  		return s->errorhandler();
  #else
***************
*** 1895,1903 ****
  			segment = send_length;
  		}
  		Py_BEGIN_ALLOW_THREADS
! 		internal_select(s, 1);
! 		n = send(s->sock_fd, buf, segment, flags);
  		Py_END_ALLOW_THREADS
  		if (n < 0) {
  			return s->errorhandler();
  		}
--- 1948,1961 ----
  			segment = send_length;
  		}
  		Py_BEGIN_ALLOW_THREADS
! 		timeout = internal_select(s, 1);
! 		if (!timeout)
! 			n = send(s->sock_fd, buf, segment, flags);
  		Py_END_ALLOW_THREADS
+ 		if (timeout) {
+ 			PyErr_SetString(socket_timeout, "timed out");
+ 			return NULL;
+ 		}
  		if (n < 0) {
  			return s->errorhandler();
  		}
***************
*** 1922,1935 ****
  sock_sendall(PySocketSockObject *s, PyObject *args)
  {
  	char *buf;
! 	int len, n, flags = 0;
  
  	if (!PyArg_ParseTuple(args, "s#|i:sendall", &buf, &len, &flags))
  		return NULL;
  
  	Py_BEGIN_ALLOW_THREADS
  	do {
! 		internal_select(s, 1);
  		n = send(s->sock_fd, buf, len, flags);
  		if (n < 0)
  			break;
--- 1980,1995 ----
  sock_sendall(PySocketSockObject *s, PyObject *args)
  {
  	char *buf;
! 	int len, n = 0, flags = 0, timeout;
  
  	if (!PyArg_ParseTuple(args, "s#|i:sendall", &buf, &len, &flags))
  		return NULL;
  
  	Py_BEGIN_ALLOW_THREADS
  	do {
! 		timeout = internal_select(s, 1);
! 		if (timeout)
! 			break;
  		n = send(s->sock_fd, buf, len, flags);
  		if (n < 0)
  			break;
***************
*** 1938,1943 ****
--- 1998,2007 ----
  	} while (len > 0);
  	Py_END_ALLOW_THREADS
  
+ 	if (timeout) {
+ 		PyErr_SetString(socket_timeout, "timed out");
+ 		return NULL;
+ 	}
  	if (n < 0)
  		return s->errorhandler();
  
***************
*** 1962,1968 ****
  	PyObject *addro;
  	char *buf;
  	struct sockaddr *addr;
! 	int addrlen, len, n, flags;
  
  	flags = 0;
  	if (!PyArg_ParseTuple(args, "s#O:sendto", &buf, &len, &addro)) {
--- 2026,2032 ----
  	PyObject *addro;
  	char *buf;
  	struct sockaddr *addr;
! 	int addrlen, len, n = 0, flags, timeout;
  
  	flags = 0;
  	if (!PyArg_ParseTuple(args, "s#O:sendto", &buf, &len, &addro)) {
***************
*** 1976,1985 ****
  		return NULL;
  
  	Py_BEGIN_ALLOW_THREADS
! 	internal_select(s, 1);
! 	n = sendto(s->sock_fd, buf, len, flags, addr, addrlen);
  	Py_END_ALLOW_THREADS
  
  	if (n < 0)
  		return s->errorhandler();
  	return PyInt_FromLong((long)n);
--- 2040,2054 ----
  		return NULL;
  
  	Py_BEGIN_ALLOW_THREADS
! 	timeout = internal_select(s, 1);
! 	if (!timeout)
! 		n = sendto(s->sock_fd, buf, len, flags, addr, addrlen);
  	Py_END_ALLOW_THREADS
  
+ 	if (timeout) {
+ 		PyErr_SetString(socket_timeout, "timed out");
+ 		return NULL;
+ 	}
  	if (n < 0)
  		return s->errorhandler();
  	return PyInt_FromLong((long)n);
***************
*** 3409,3414 ****
--- 3478,3489 ----
  		return;
  	Py_INCREF(socket_gaierror);
  	PyModule_AddObject(m, "gaierror", socket_gaierror);
+ 	socket_timeout = PyErr_NewException("socket.timeout",
+ 					    socket_error, NULL);
+ 	if (socket_timeout == NULL)
+ 		return;
+ 	Py_INCREF(socket_timeout);
+ 	PyModule_AddObject(m, "timeout", socket_timeout);
  	Py_INCREF((PyObject *)&sock_type);
  	if (PyModule_AddObject(m, "SocketType",
  			       (PyObject *)&sock_type) != 0)



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


From martin@v.loewis.de  Sat Jun 28 23:45:55 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 29 Jun 2003 00:45:55 +0200
Subject: [Python-Dev] Py2.3 Todo List
In-Reply-To: <200306282142.h5SLgTX24798@pcp02138704pcs.reston01.va.comcast.net>
References: <Pine.LNX.4.44.0306171515380.2886-100000@penguin.theopalgroup.com>
 <200306282142.h5SLgTX24798@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <m3n0g1izx8.fsf@mira.informatik.hu-berlin.de>

Guido van Rossum <guido@python.org> writes:

> Can someone review this and apply if it's okay?  From this description
> I'd be okay with including it, but I have no time to review.

It's checked in already.

Martin


From lists@webcrunchers.com  Sun Jun 29 03:53:43 2003
From: lists@webcrunchers.com (John D.)
Date: Sat, 28 Jun 2003 19:53:43 -0700
Subject: [Python-Dev] Proposed DNS query library
Message-ID: <v03110770bb23fa18adab@[192.168.0.2]>

Python has everything else, but it doesn't have a nameserver lookup class.
I propose creating a library which will perform the equivalent of the "dig" or "nslookup" commands. My own application is using it to query a DNS for mx records as a preface to using smtplib. (Perhaps this should be added to smtplib?)

dnslib? diglib? domainlib? nslookuplib?

Possibly:
servers=dnsquery([nameserver],[name],[type],[class])
i.e.
>>>from dnslib import dnsquery
>>>d=dnsquery(,"google.com","mx")
>>>print d
['10 smtp1.google.com','20 smtp2.google.com']

It would have the usual options, etc.

Is this a good idea or do I need to spend more time in the oven?
(or worse, it already exists and I overlooked it?)




From halley@play-bow.org  Sun Jun 29 04:15:10 2003
From: halley@play-bow.org (Bob Halley)
Date: 28 Jun 2003 20:15:10 -0700
Subject: [Python-Dev] Proposed DNS query library
In-Reply-To: <v03110770bb23fa18adab@[192.168.0.2]>
References: <v03110770bb23fa18adab@[192.168.0.2]>
Message-ID: <m3d6gxingh.fsf@woof.play-bow.org>

"John D." <lists@webcrunchers.com> writes:

> Python has everything else, but it doesn't have a nameserver lookup
> class.  I propose creating a library which will perform the
> equivalent of the "dig" or "nslookup" commands. My own application
> is using it to query a DNS for mx records as a preface to using
> smtplib. (Perhaps this should be added to smtplib?)

> Is this a good idea or do I need to spend more time in the oven?
> (or worse, it already exists and I overlooked it?)

My dnspython package ( http://www.dnspython.org ) can do this, and a
lot more.  Here's a program which gets and prints MX records.

        import dns.resolver

        answers = dns.resolver.query('dnspython.org', 'MX')
        for rdata in answers:
            print 'Host', rdata.exchange, 'has preference', rdata.preference

/Bob


From neal@metaslash.com  Sun Jun 29 05:54:19 2003
From: neal@metaslash.com (Neal Norwitz)
Date: Sun, 29 Jun 2003 00:54:19 -0400
Subject: [Python-Dev] Problems in stdlib before 2.3b2
Message-ID: <20030629045419.GE1310@epoch.metaslash.com>

There are a couple of problems in the stdlib.  These are the most
serious ones that I found:

        trace.py:       uses threading.settrace(), but settrace doesn't
                        exist in the threading module staring around line 444
        xmlrpclib.py:   around line 734, Fault() is instantiated with
                        only keyword arguments, there are 2 required
                        arguments.  I don't know how to get the
                        faultCode and faultString.

        xml/dom/expatbuilder.py:
                        line 272, missing self. before curNode
                        I added this to Python,
                        does this need to go into PyXML?

Unfortunately, this was just a quick review.

Neal


From fdrake@acm.org  Sun Jun 29 07:49:06 2003
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Sun, 29 Jun 2003 02:49:06 -0400
Subject: [Python-Dev] Problems in stdlib before 2.3b2
In-Reply-To: <20030629045419.GE1310@epoch.metaslash.com>
References: <20030629045419.GE1310@epoch.metaslash.com>
Message-ID: <16126.35810.588718.935829@grendel.zope.com>

Neal Norwitz writes:
 >         xml/dom/expatbuilder.py:
 >                         line 272, missing self. before curNode
 >                         I added this to Python,
 >                         does this need to go into PyXML?

Yes; I'll take care of this.  Thanks!


  -Fred

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


From guido@python.org  Sun Jun 29 11:19:08 2003
From: guido@python.org (Guido van Rossum)
Date: Sun, 29 Jun 2003 06:19:08 -0400
Subject: [Python-Dev] Problems in stdlib before 2.3b2
In-Reply-To: "Your message of Sun, 29 Jun 2003 00:54:19 EDT."
 <20030629045419.GE1310@epoch.metaslash.com>
References: <20030629045419.GE1310@epoch.metaslash.com>
Message-ID: <200306291019.h5TAJ8U01605@pcp02138704pcs.reston01.va.comcast.net>

> There are a couple of problems in the stdlib.  These are the most
> serious ones that I found:
> 
>         trace.py:       uses threading.settrace(), but settrace doesn't
>                         exist in the threading module staring around line 444

A short while ago, Jeremy showed me code that added settrace() to
threading.  Apparently it wasn't checked in.  He checked in the change
to trace.py on June 26.  If he doesn't check in the corresponding
changes to threading.py, I suggest to remove or comment out the calls
to threading.settrace() before releasing 2.3b2.

>         xmlrpclib.py:   around line 734, Fault() is instantiated with
>                         only keyword arguments, there are 2 required
>                         arguments.  I don't know how to get the
>                         faultCode and faultString.

I saw this line was my checkin when switching from apply() to *args,
**kwds calls, but the original code did not provide any positional
arguments either.  This code has been like this since 2001.

Given the comment at the start of the Unmarshaller class ("and again,
if you don't understand what's going on in here, that's perfectly
ok"), it's not inconceivable that the stack actually contains the
required keywords, so I don't even know if this is an actual bug.

Or possibly it is, but that particular condition is never true.

I'm cc'ing Fredrik, maybe he remembers.  Not a 2.3b2 showstopper IMO.

>         xml/dom/expatbuilder.py:
>                         line 272, missing self. before curNode
>                         I added this to Python,
>                         does this need to go into PyXML?

Probably, I think there are some PyXML folks here who can take care of
it.

> Unfortunately, this was just a quick review.

Thanks!

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


From martin@v.loewis.de  Sun Jun 29 12:33:30 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 29 Jun 2003 13:33:30 +0200
Subject: [Python-Dev] Re: SF CVS hosed?
In-Reply-To: <16121.57706.255147.73062@gargle.gargle.HOWL>
References: <200306200657.h5K6virT011718@localhost.localdomain>
 <B722EABC-A2F9-11D7-B66E-0030655234CE@cwi.nl>
 <16121.57706.255147.73062@gargle.gargle.HOWL>
Message-ID: <m31xxdw22d.fsf@mira.informatik.hu-berlin.de>

Matthias Klose <doko@cs.tu-berlin.de> writes:

> I still am not able to complete a checkout/update as an anonymous
> user. For the meantime, please could somebody provide snapshots (maybe
> weekly) on some site?

I have now created

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python.tgz

This is a daily snapshot, created from downloading the daily CVS
tarball and checking out the HEAD revision, at 2:45 local time (MESZ).

Regards,
Martin


From skip@mojam.com  Sun Jun 29 13:00:19 2003
From: skip@mojam.com (Skip Montanaro)
Date: Sun, 29 Jun 2003 07:00:19 -0500
Subject: [Python-Dev] Weekly Python Bug/Patch Summary
Message-ID: <200306291200.h5TC0JO03210@manatee.mojam.com>

Bug/Patch Summary
-----------------

359 open / 3765 total bugs (no change)
162 open / 2241 total patches (no change)

New Bugs
--------

inspect.getmembers broken (?) (2003-06-23)
	http://python.org/sf/759525
asyncore.py and "handle_error" (2003-06-25)
	http://python.org/sf/760475
Tutorial: executable scripts on Windows (2003-06-25)
	http://python.org/sf/760657
tkMessageBox.askyesnocancel missing (2003-06-26)
	http://python.org/sf/761144
Failure in comparing unicode string (2003-06-26)
	http://python.org/sf/761267
HTMLParser chokes on my.yahoo.com output (2003-06-26)
	http://python.org/sf/761452
readline()/readlines() (2003-06-27)
	http://python.org/sf/761787
popen2.Popen3 and popen2.Popen4 leaks filedescriptors (2003-06-27)
	http://python.org/sf/761888
PackMan needs to be able to install outside site-packages (2003-06-27)
	http://python.org/sf/762147
bug in signal.signal -- raises SystemError (2003-06-27)
	http://python.org/sf/762198
Python segfaults when sys.stdout is changed in getattr (2003-06-28)
	http://python.org/sf/762455
problem building c extension with minGW on Windows (2003-06-29)
	http://python.org/sf/762614

New Patches
-----------

extending readline functionality (2003-01-27)
	http://python.org/sf/675551
curses has_key emulation fix (2003-06-23)
	http://python.org/sf/759208
add time elapsed to gc debug output (2003-06-25)
	http://python.org/sf/760990
adding BaseSet.filter and Set.filter_update (2003-06-26)
	http://python.org/sf/761104
DISTUTILS_DEBUG undocumented (2003-06-26)
	http://python.org/sf/761401
readline module that checks signals (2003-06-27)
	http://python.org/sf/761863
patch against readline module to handle signals (2003-06-27)
	http://python.org/sf/761865
-DPIC should be added for the -fPIC case (2003-06-27)
	http://python.org/sf/761969
pep-283 outdated (2003-06-28)
	http://python.org/sf/762502

Closed Bugs
-----------

'testlist&quot; undefined in grammar (2002-05-04)
	http://python.org/sf/552262
inspect and object instances (2002-10-08)
	http://python.org/sf/620190
Tutorial: info on Source Code Encoding is missing (2003-02-09)
	http://python.org/sf/683486
How to make a class iterable using a member generator. (2003-03-03)
	http://python.org/sf/696777
os.utime can fail with TypeError (2003-03-13)
	http://python.org/sf/703066
Broken links for grammar in docs (2003-04-23)
	http://python.org/sf/726150
What's new in Python2.3b1 HTML generation. (2003-04-28)
	http://python.org/sf/729297
Python-Profiler bug: Bad call (2003-05-28)
	http://python.org/sf/744841
threads broke on FreeBSD current (2003-05-28)
	http://python.org/sf/745320
make test errors Tru64 UNIX V5.1A (2003-06-02)
	http://python.org/sf/747460
Need to register PythonLauncher as handler for .py (2003-06-19)
	http://python.org/sf/757542
logging module docs (2003-06-20)
	http://python.org/sf/757821
Additional index items, other minor details (2003-06-20)
	http://python.org/sf/757822
socket timeout exception unhelpful (2003-06-20)
	http://python.org/sf/758239

Closed Patches
--------------

improve pydoc handling of extension types (2003-01-22)
	http://python.org/sf/672855
Several objects don't decref tmp on failure in subtype_new (2003-03-14)
	http://python.org/sf/703666
Patch to make shlex accept escaped quotes in strings. (2003-04-12)
	http://python.org/sf/720329
Trivial improvement to NameError message (2003-05-12)
	http://python.org/sf/736730
Port tests to unittest (Part 2) (2003-05-13)
	http://python.org/sf/736962
'compiler' module bug with 'import foo.bar as baz' (2003-06-06)
	http://python.org/sf/750008
Handle keyboard interrupts in SSL module (2003-06-10)
	http://python.org/sf/751916
Enhance xrange description by mentioning itertools.repeat (2003-06-14)
	http://python.org/sf/754632
re reads an uninitialized memory (2003-06-17)
	http://python.org/sf/756032
test_itertools for roundrobin() and window() (2003-06-17)
	http://python.org/sf/756255
Bare except in ZipFile.testzip() (2003-06-18)
	http://python.org/sf/756996


From PieterB <pieterb@gewis.nl>  Sun Jun 29 13:01:07 2003
From: PieterB <pieterb@gewis.nl> (PieterB)
Date: Sun, 29 Jun 2003 14:01:07 +0200 (CEST)
Subject: [Python-Dev] Running tests on freebsd5
Message-ID: <20030629120107.B424521106@gewis.win.tue.nl>

Hi,

I just checked out the Python CVS head, ran configure and compiled
succesfully on FreeBSD 5.0. I then ran 'make tests', and had two
failing tests. I don't think these errors are related to FreeBSD5.0,
so I post them here. Can somebody add the lists of tests for
'freebsd5' to regrtest.py, and have a look at these tracebacks?

PieterB
--
http://zwiki.org/PieterB

...
2 tests failed:
    test_socket test_tempfile
34 tests skipped:
    test_aepack test_al test_bsddb test_bsddb185 test_bsddb3 test_cd
    test_cl test_curses test_dbm test_email_codecs test_fcntl
    test_gdbm test_gl test_imgfile test_ioctl test_linuxaudiodev
    test_locale test_macfs test_macostools test_mpz test_nis
    test_normalization test_ossaudiodev test_pep277 test_plistlib
    test_scriptpackages test_socket_ssl test_socketserver
    test_sunaudiodev test_timeout test_unicode_file test_urllibnet
    test_winreg test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on freebsd5.

------------------------------------------------------------------

When running test_socket.py, I get the following traceback:
Ran 51 tests in 2.470s

FAILED (errors=1)
Traceback (most recent call last):
  File "test_socket.py", line 755, in ?
    test_main()
  File "test_socket.py", line 752, in test_main
    test_support.run_unittest(*tests)
  File ".../src/Lib/test/test_support.py",
line 259, in run_unittest
    run_suite(suite, testclass)
  File ".../src/Lib/test/test_support.py", line 247, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "test_socket.py", line 215, in testCrucialConstants
    socket.SOCK_RDM
AttributeError: 'module' object has no attribute 'SOCK_RDM'

-----------------------------------------------------------------
When I run test_tempfile.py I get:

Ran 34 tests in 0.703s
FAILED (failures=1)
Traceback (most recent call last):
  File "test_tempfile.py", line 651, in ?
    test_main()
  File "test_tempfile.py", line 648, in test_main
    test_support.run_unittest(*test_classes)
  File ".../src/Lib/test/test_support.py", line 259, in run_unittest
    run_suite(suite, testclass)
  File ".../src/Lib/test/test_support.py", line 247, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "test_tempfile.py", line 299, in test_noinherit
    self.failIf(retval > 0, "child process reports failure")
  File ".../src/Lib/unittest.py", line 264, in failIf
    if expr: raise self.failureException, msg
AssertionError: child process reports failure



From martin@v.loewis.de  Sun Jun 29 14:28:42 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 29 Jun 2003 15:28:42 +0200
Subject: [Python-Dev] Running tests on freebsd5
In-Reply-To: <20030629120107.B424521106@gewis.win.tue.nl>
References: <20030629120107.B424521106@gewis.win.tue.nl>
Message-ID: <m3wuf5ui5x.fsf@mira.informatik.hu-berlin.de>

PieterB <pieterb@gewis.nl> writes:

> AttributeError: 'module' object has no attribute 'SOCK_RDM'

It appears your system either does not support SOCK_RDM, or somehow
Python failed to pickup the definition of SOCK_RDM. An expert for your
system would have to determine which one it is. He would then need to
investigate whether not providing this constant is a deliberate
omission, a known bug, or an unknown bug.

If it is a known or unknown bug, the test deserves to fail - Python
tests often fail because of bugs in the system.

If this is a deliberate omission, somebody should give us the
rationale for this omission, so we can reconsider not to treat
SOCK_RDM as a crucial constant.

> AssertionError: child process reports failure

You will have to find out in more detail why this happens. Find out
what sys.executable, tester, v, and d are, then find out whether the
process is invoked correctly.

If it is not invoked, find out why.

If it is invoked, find out whether it returns 1, or some other
value. If it returns some other value, find out which value and
why. If it returns 1, find out which of the two sys.exits in
tf_inherit_check.py is taken. And so on.

Regards,
Martin



From barry@python.org  Sun Jun 29 18:07:27 2003
From: barry@python.org (Barry Warsaw)
Date: 29 Jun 2003 13:07:27 -0400
Subject: [Python-Dev] Re: Activating `-i' from inside a script?
In-Reply-To: <200306282140.h5SLeBt24770@pcp02138704pcs.reston01.va.comcast.net>
References: <16124.12542.188534.731123@montanaro.dyndns.org>
 <200306282140.h5SLeBt24770@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <1056906446.6280.73.camel@anthem>

On Sat, 2003-06-28 at 17:40, Guido van Rossum wrote:

> > I can't see that it would affect the functioning of any programs other than
> > those which set PYTHONINSPECT now.  (But why would they do that and what's
> > the likelihood such programs exist?)
> > 
> > Any chance this could be squeezed in?  It seems rather elegant:
> > 
> >     try:
> >         something which fails
> >     except:
> >         os.environ["PYTHONINSPECT"] = 1
> >         raise
> > 
> > (I know we're at beta1, and the programmer could re-run with -i.  But
> > still...)
> 
> Looks harmless to me.  Thomas Heller's alternative really does
> something different.  Skip can check it in.

I just committed this for 2.3b2.

-Barry




From barry@python.org  Sun Jun 29 19:15:19 2003
From: barry@python.org (Barry Warsaw)
Date: 29 Jun 2003 14:15:19 -0400
Subject: [Python-Dev] Python 2.3b2 branch tag created
Message-ID: <1056910518.6280.82.camel@anthem>

I've just tagged and branched Python 2.3b2, so the trunk is now open for
checkins again.  Of course the r23b2-branch is closed so we can spin the
release.

-Barry




From skip@pobox.com  Sun Jun 29 20:18:52 2003
From: skip@pobox.com (Skip Montanaro)
Date: Sun, 29 Jun 2003 14:18:52 -0500
Subject: [Python-Dev] Re: Activating `-i' from inside a script?
In-Reply-To: <1056906446.6280.73.camel@anthem>
References: <16124.12542.188534.731123@montanaro.dyndns.org>
 <200306282140.h5SLeBt24770@pcp02138704pcs.reston01.va.comcast.net>
 <1056906446.6280.73.camel@anthem>
Message-ID: <16127.15260.930157.245370@montanaro.dyndns.org>

    Guido> Looks harmless to me.  Thomas Heller's alternative really does
    Guido> something different.  Skip can check it in.

    Barry> I just committed this for 2.3b2.

Thanks, I've been offline most of the weekend.

Skip





From andymac@bullseye.apana.org.au  Sun Jun 29 16:26:55 2003
From: andymac@bullseye.apana.org.au (Andrew MacIntyre)
Date: Mon, 30 Jun 2003 01:26:55 +1000 (EST)
Subject: [Python-Dev] Running tests on freebsd5
In-Reply-To: <20030629120107.B424521106@gewis.win.tue.nl>
References: <20030629120107.B424521106@gewis.win.tue.nl>
Message-ID: <20030630010549.B15576@bullseye.apana.org.au>

On Sun, 29 Jun 2003, PieterB wrote:

> 2 tests failed:
>     test_socket test_tempfile

I'm aware of these 2, and there are some other niggling issues with
FreeBSD 5.x that I've been looking at.  Some of these issues won't
stabilise until the FreeBSD team choose to declare 5.x a "stable" branch.
5.0 in particular is not a good release to target for solid support.

There are a couple of issues on FreeBSD 4.x that need attention too, and
as 4.x is still the official stable release, these will likely get my
priority.

BTW, a bug report on SF is a more appropriate place for a report like
this.

Regards,
Andrew.

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac@pcug.org.au             (alt) |        Belconnen  ACT  2616
Web:    http://www.andymac.org/               |        Australia


From drifty@alum.berkeley.edu  Sun Jun 29 21:39:19 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Sun, 29 Jun 2003 13:39:19 -0700
Subject: [Python-Dev] No Net at home
In-Reply-To: <3EF268AD.7060308@ocf.berkeley.edu>
References: <3EF268AD.7060308@ocf.berkeley.edu>
Message-ID: <3EFF4E77.2070001@ocf.berkeley.edu>

My Internet connection is *finally* back.  I now have 818 emails of 
non-spam (as flagged by Spam Assassin) to go through.

Since it is already so late in the month I am just going to do a 
month-long summary.

-Brett



From fredrik@pythonware.com  Sun Jun 29 21:53:51 2003
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sun, 29 Jun 2003 22:53:51 +0200
Subject: [Python-Dev] Problems in stdlib before 2.3b2
References: <20030629045419.GE1310@epoch.metaslash.com> <200306291019.h5TAJ8U01605@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <01ca01c33e80$8e0a6dd0$ced241d5@hagrid>

(hi python-dev, long time no see)

Guido wrote:

> 
> >         xmlrpclib.py:   around line 734, Fault() is instantiated with
> >                         only keyword arguments, there are 2 required
> >                         arguments.  I don't know how to get the
> >                         faultCode and faultString.
> 
> I saw this line was my checkin when switching from apply() to *args,
> **kwds calls, but the original code did not provide any positional
> arguments either.  This code has been like this since 2001.
> 
> Given the comment at the start of the Unmarshaller class ("and again,
> if you don't understand what's going on in here, that's perfectly
> ok"), it's not inconceivable that the stack actually contains the
> required keywords, so I don't even know if this is an actual bug.
> 
> Or possibly it is, but that particular condition is never true.

Not unless the other end is sending you junk, in case you want
an exception at that point (one could argue if the exception you
get is really the exception you want, but nobody's complained in
the last four years, so we're probably safe).

regards /F


From L.C. \(Laurentiu C. Badea\)" <python-dev-20030629@wotevah.com  Sun Jun 29 22:12:19 2003
From: L.C. \(Laurentiu C. Badea\)" <python-dev-20030629@wotevah.com (L.C. (Laurentiu C. Badea))
Date: Sun, 29 Jun 2003 14:12:19 -0700
Subject: [Python-Dev] threads duplicated on fork() prevent child from terminating properly
Message-ID: <20030629211219.29344.qmail@java1.p3.infostreet.com>

Hello,

I am reposting this here as c.l.py didn't produce too many responses...
If anybody has any pointers on how to fix (or where to look), I would appreciate
it. I've tried this on 2.1 (RedHat 7.3), 2.2.1 and 2.2.3 (RedHat 9).

The simple program below launches a thread, then fork()s and attempts to clean
the mess up on exit like the nice process it is. Only problem is, the child does
not want to die, looks like it detached and is sitting on schedule_timeout()
(according to ps).

This is, I suspect, because the thread and its state are duplicated on fork()
but the state structure is not updated to indicate that the thread is in fact
NOT active so the child is fooled into waiting for its termination, which will
never happen. If the parent terminates without executing waitpid(), the child
will hang there indefinitely wasting resources.

I can see the following ways to actually have it finish normally:

1) parent join()-s all the threads before fork(): not always possible.

2) parent kill()-s the child: not nice.

3) child does os._exit(): IMHO the best option but os._exit() is not described
as an elegant exit method. Using this also means that if all exceptions are not
handled in the thread, we risk the same problem.

I guess I have answered 90% of my question (which I have not stated) already. 
At any rate, it seems to me that this matter should be handled internally in
Python's core. Regardless of whether os._exit() is mandated for use in child
processes or not instead of sys.exit() or other exception handlers, I find it
somewhat illogical to have the child process wait for a thread that is not
really there. I would probably expect that os.fork() would clean up the thread
list in the child unless we know (Solaris) that the threads are really there.

import os, sys
from threading import *

def log( message ):
    print ( "%d %s" % (os.getpid(), message) )


if __name__ == "__main__":
    log( "is parent" )
    t = Thread()
    t.start()
    # t.join() # OPTION 1

    childPID = os.fork()
    if childPID == 0:
        log( "is child" )

    log( "threads: %s" % str(enumerate()) )

    if childPID == 0:
        #os._exit(0) # OPTION 2
        pass

    else:
        t.join()
        #os.kill( childPID, 15 ) # OPTION 3
        log( "parent done waiting for %s, now waiting for %d" %
             (t.getName(), childPID) )
        os.waitpid(childPID, 0)
        
    log( "exiting" )

Thank you,
-- 
L.C. (Laurentiu Badea)


From Jack.Jansen@cwi.nl  Sun Jun 29 22:22:08 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Sun, 29 Jun 2003 23:22:08 +0200
Subject: [Python-Dev] threads duplicated on fork() prevent child from terminating properly
In-Reply-To: <20030629211219.29344.qmail@java1.p3.infostreet.com>
Message-ID: <BD4AE1D7-AA77-11D7-B985-000A27B19B96@cwi.nl>

On zondag, jun 29, 2003, at 23:12 Europe/Amsterdam, L.C. (Laurentiu C. 
Badea) wrote:
> The simple program below launches a thread, then fork()s and attempts 
> to clean
> the mess up on exit like the nice process it is. Only problem is, the 
> child does
> not want to die, looks like it detached and is sitting on 
> schedule_timeout()
> (according to ps).

I haven't looked at it in detail, but this could well be a problem. And 
if it is
then it may need a different solution as your suggestion (clean up the 
mess in
os.fork()), as fork() could conceivably be called from extension 
modules. Hmm,
no, these should be good citizens and call PyOS_AfterFork(), I guess.

Anyway: you should submit a bug report for this so it doesn't get lost.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From hfastjava@yahoo.com  Sun Jun 29 23:45:04 2003
From: hfastjava@yahoo.com (Hunter Peress)
Date: Sun, 29 Jun 2003 15:45:04 -0700 (PDT)
Subject: [Python-Dev] threads duplicated on fork() prevent child from terminating properly
Message-ID: <20030629224504.8997.qmail@web41315.mail.yahoo.com>

when i hear redhat 9 and threads....i think of the completely new NTPL threads library
just keep that in mind.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


From tdelaney@avaya.com  Mon Jun 30 02:02:53 2003
From: tdelaney@avaya.com (Delaney, Timothy C (Timothy))
Date: Mon, 30 Jun 2003 11:02:53 +1000
Subject: [Python-Dev] Running tests on freebsd5
Message-ID: <338366A6D2E2CA4C9DAEAE652E12A1DE797BA3@au3010avexu1.global.avaya.com>

> From: Andrew MacIntyre [mailto:andymac@bullseye.apana.org.au]
>=20
> On Sun, 29 Jun 2003, PieterB wrote:
>=20
> > 2 tests failed:
> >     test_socket test_tempfile
>=20
> I'm aware of these 2, and there are some other niggling issues with
> FreeBSD 5.x that I've been looking at.  Some of these issues won't
> stabilise until the FreeBSD team choose to declare 5.x a=20
> "stable" branch.
> 5.0 in particular is not a good release to target for solid support.

I might have the opportunity to at least run the tests on FreeBSD 5.1. I =
just set up my first FreeBSD system on the weekend :)

However, it will probably have to wait until the weekend when I have =
time to actually *configure* the system - I got it to the stage of being =
able to run KDE and that was it - then I felt I'd earned my chance to =
watch my "Spirited Away" DVD :)

Tim Delaney


From barry@python.org  Mon Jun 30 02:57:43 2003
From: barry@python.org (Barry Warsaw)
Date: 29 Jun 2003 21:57:43 -0400
Subject: [Python-Dev] RELEASED: Python 2.3b2
Message-ID: <1056938263.5689.25.camel@geddy>

Python 2.3b2 is the second beta release of Python 2.3.  There have be a
slew of fixes since the first beta, and a few new "features".  Our goal
is to have a final Python 2.3 release by early August, so we encourage
lots of testing for this beta.  Highlights since beta 1 include:

- IDLEfork has been merged in and now replaces the old IDLE.

- The Windows installer now ships with Tcl/Tk 8.4.3.

- list.index() has grown optional `start' and `end' arguments.

- A new C-only API function PyThreadState_SetAsyncExc() which can be
  used to interrupt threads by sending them exceptions.

- Python programs can enter the interactive prompt at program exit by 
  setting the PYTHONINSPECT environment variable.

- Many new doctest improvements, including the ability to write doctest
  based unit tests.

- New and improved documentation for writing new types in C that 
  participate in cyclic garbage collection.

There is at least one known bug: we have seen crashes on both Windows
and Linux with certain interactions between test_logging and
test_bsddb3.  We intend to fix this for the next release. 

For more highlights, see http://www.python.org/2.3/highlights.html

Other new stuff since Python 2.2:

- Many new and improved library modules, e.g. sets, heapq, datetime,
  textwrap, optparse, logging, bsddb, bz2, tarfile,
  ossaudiodev, and a new random number generator based on the highly
  acclaimed Mersenne Twister algorithm (with a period of 2**19937-1!).

- New builtin enumerate(): an iterator yielding (index, item) pairs.

- Extended slices, e.g. "hello"[::-1] returns "olleh".

- Universal newlines mode for reading files (converts \r, \n and \r\n
  all into \n).

- Source code encoding declarations.  (PEP 263)

- Import from zip files.  (PEP 273 and PEP 302)

- FutureWarning issued for "unsigned" operations on ints.  (PEP 237)

- Faster list.sort() is now stable.

- Unicode filenames on Windows.

- Karatsuba long multiplication (running time O(N**1.58) instead of
  O(N**2)).

If you have an important Python application, we strongly recommend that
you try it out with a beta release and report any incompatibilities or
other problems you may encounter, so that they can be fixed before the
final release.  To report problems, use the SourceForge bug tracker:

  http://sourceforge.net/tracker/?group_id=5470&atid=105470

Enjoy,
-Barry




From till@score.is.tsukuba.ac.jp  Mon Jun 30 03:12:41 2003
From: till@score.is.tsukuba.ac.jp (Till Plewe)
Date: Mon, 30 Jun 2003 11:12:41 +0900
Subject: [Python-Dev] Running tests on freebsd5
In-Reply-To: <20030629120107.B424521106@gewis.win.tue.nl>
References: <20030629120107.B424521106@gewis.win.tue.nl>
Message-ID: <20030630021241.GA20678@plewe.is.tsukuba.ac.jp>

On Sun, Jun 29, 2003 at 02:01:07PM +0200, PieterB wrote:
> Hi,
> 
> I just checked out the Python CVS head, ran configure and compiled
> succesfully on FreeBSD 5.0. I then ran 'make tests', and had two
> failing tests. I don't think these errors are related to FreeBSD5.0,
> so I post them here. 

Unfortunately, at least one of them is:

$man socket says

"...
The types SOCK_RAW, which is available only to the super-user, and
SOCK_RDM, which is planned, but not yet implemented, are not described
here.
..."

> When running test_socket.py, I get the following traceback:
> Ran 51 tests in 2.470s
> 
...
>   File "test_socket.py", line 215, in testCrucialConstants
>     socket.SOCK_RDM
> AttributeError: 'module' object has no attribute 'SOCK_RDM'
> 

- Till


From NAIVS-CAPETOWNZACAPEX01@verisign.com  Mon Jun 30 03:10:42 2003
From: NAIVS-CAPETOWNZACAPEX01@verisign.com (GroupShield for Exchange (ZACAPEX01))
Date: Mon, 30 Jun 2003 04:10:42 +0200
Subject: [Python-Dev] ALERT -  GroupShield ticket number OA2751_1056939039_ZACAPEX01_3
 was generated
Message-ID: <AC7E8D43F95DD041A175D19F74AAB294013EB412@zacapex01.cpt.thawte.com>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C33EAC.CEE50B40
Content-Type: text/plain

Action Taken:
The attachment was quarantined from the message and replaced with a text
file informing the recipient of the action taken.

To:
personal-premium@thawte.com <personal-premium@thawte.com>

From:
python-dev@python.org <python-dev@python.org>

Sent:
-556770176,29572780

Subject:
Re: Application

Attachment Details:-

Attachment Name: your_details.zip
File: your_details.zip
Infected? No
Repaired? No
Blocked? Yes
Deleted? No
Virus Name: 



	

------_=_NextPart_000_01C33EAC.CEE50B40
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IiwCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGQAAAElQTS5BbnRp
LVZpcnVzLlJlcG9ydC40NQAnCAEFgAMADgAAANMHBgAeAAQACgAqAAEANwEBIIADAA4AAADTBwYA
HgAEAAoAKgABADcBAQmAAQAhAAAANkM5OEMwN0JCMUE5MDY0NzhCOUYxMDIyOTZCRDQwQTQAIAcB
BIABAE8AAABBTEVSVCAtICBHcm91cFNoaWVsZCB0aWNrZXQgbnVtYmVyIE9BMjc1MV8xMDU2OTM5
MDM5X1pBQ0FQRVgwMV8zIHdhcyBnZW5lcmF0ZWQAOxgBDYAEAAIAAAACAAIAAQOQBgBwBgAAIAAA
AEAAOQBAC+XOrD7DAQMA8T8JBAAAHgAxQAEAAAAYAAAATkFJVlMtQ0FQRVRPV05aQUNBUEVYMDEA
AwAaQAAAAAAeADBAAQAAABgAAABOQUlWUy1DQVBFVE9XTlpBQ0FQRVgwMQADABlAAAAAAAIBCRAB
AAAAyAEAAMQBAAAbAwAATFpGdWYnmRiHAAoBDQNDdGV4dAH3/wKkA+QF6wKDAFAC8wa0AoMmMgPF
AgBjaArAc2XYdDAgBxMCgH0KgAjPfwnZAoAKhAs3EsIB0BPgY4R0aQIgIFRhawnwBjoKowqAVGhl
IGEbAkAA0GgHgAIwIHdhuQQgcXUKwABwF/BuCYAyIANSIHQZIQeBc2G6ZxkxbhrgFUALUWMa0f8D
8BtQGUAbQA8BGvADEBkw0wuAAhBybQuAZxtDFUDOYwUgCJAZ0W9mG0MA0LcX8wGQGGEuGKUYpm8Y
lppwBJBzAiAHQC1wFUCRHkB1bUAbUGF3DvC2LgWgGzA8Ij8jSD4gvLZGA2Eht3kbUAIgLQEA9HZA
J2QuBbAecCPwJ38fKIElvQZgAjAYli01NQA2NzcwMTc2LMgyOTUBwDc4AUAqTBh1YmoFkCtHUmU6
5RPgcAtQaWMZUBgBILwaQRloRBOwC3BsczpmLS/PGYZOYQeALvB5zQhhXwEAMXMuegUgJjZ3HbEz
vzTGSR4ALiEJgD9tB7BvLmcKsGkVQTeZQu0U0GMYYDeBWQeQGKUxUOsdwDdsVjiAdQehM4MgvBM8
/QGRIH0+oAMA/T/kBAAAAgFxAAEAAAAWAAAAAcM+rM7lbMbymZDMRVmIG5d4piCFIQAAAwAmAAAA
AAADADYAAAAAAB4AcAABAAAATwAAAEFMRVJUIC0gIEdyb3VwU2hpZWxkIHRpY2tldCBudW1iZXIg
T0EyNzUxXzEwNTY5MzkwMzlfWkFDQVBFWDAxXzMgd2FzIGdlbmVyYXRlZAAAAgFHAAEAAAA1AAAA
Yz1VUzthPSA7cD1WRVJJU0lHTjtsPVpBQ0FQRVgwMS0wMzA2MzAwMjEwNDJaLTIwNDgxOQAAAAAC
Afk/AQAAAGAAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089VkVSSVNJR04vT1U9VlMt
Q0FQRVRPV04vQ049UkVDSVBJRU5UUy9DTj1OQUlWUy1DQVBFVE9XTlpBQ0FQRVgwMQAeAPg/AQAA
ACUAAABHcm91cFNoaWVsZCBmb3IgRXhjaGFuZ2UgKFpBQ0FQRVgwMSkAAAAAHgA4QAEAAAAYAAAA
TkFJVlMtQ0FQRVRPV05aQUNBUEVYMDEAAgH7PwEAAABgAAAAAAAAANynQMjAQhAatLkIACsv4YIB
AAAAAAAAAC9PPVZFUklTSUdOL09VPVZTLUNBUEVUT1dOL0NOPVJFQ0lQSUVOVFMvQ049TkFJVlMt
Q0FQRVRPV05aQUNBUEVYMDEAHgD6PwEAAAAlAAAAR3JvdXBTaGllbGQgZm9yIEV4Y2hhbmdlICha
QUNBUEVYMDEpAAAAAB4AOUABAAAAGAAAAE5BSVZTLUNBUEVUT1dOWkFDQVBFWDAxAEAABzC6993O
rD7DAUAACDAwqO7OrD7DAR4APQABAAAAAQAAAAAAAAAeAB0OAQAAAE8AAABBTEVSVCAtICBHcm91
cFNoaWVsZCB0aWNrZXQgbnVtYmVyIE9BMjc1MV8xMDU2OTM5MDM5X1pBQ0FQRVgwMV8zIHdhcyBn
ZW5lcmF0ZWQAAB4ANRABAAAARAAAADxBQzdFOEQ0M0Y5NUREMDQxQTE3NUQxOUY3NEFBQjI5NDAx
M0VCNDEyQHphY2FwZXgwMS5jcHQudGhhd3RlLmNvbT4ACwApAAAAAAALACMAAAAAAAMABhDSlnv4
AwAHEH4BAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAQUNUSU9OVEFLRU46VEhFQVRUQUNI
TUVOVFdBU1FVQVJBTlRJTkVERlJPTVRIRU1FU1NBR0VBTkRSRVBMQUNFRFdJVEhBVEVYVEZJTEVJ
TkZPUk1JTkdUSEVSRUNJUElFTlRPRgAAAAACAX8AAQAAAEQAAAA8QUM3RThENDNGOTVERDA0MUEx
NzVEMTlGNzRBQUIyOTQwMTNFQjQxMkB6YWNhcGV4MDEuY3B0LnRoYXd0ZS5jb20+AHqk

------_=_NextPart_000_01C33EAC.CEE50B40--


From postmaster@mailservice.be  Mon Jun 30 03:25:43 2003
From: postmaster@mailservice.be (postmaster@mailservice.be)
Date: Mon, 30 Jun 2003 04:25:43 +0200
Subject: [Python-Dev] MDaemon Warning - Virus Found
Message-ID: <MDAEMON6924200306300425.AA2543367@mailservice.be>

The following message had attachment(s) which contained viruses:

>From      : python-dev@python.org
To        : sales@rarsoft.be
Subject   : 
Date      : Mon, 30 Jun 2003 6:53:34 +0430
Message-ID: 

Attachment                    Virus name               Action taken
------------------------------------------------------------------------------
your_details.zip              I-Worm.Sobig.gen         Removed




From tim.one@comcast.net  Mon Jun 30 03:38:44 2003
From: tim.one@comcast.net (Tim Peters)
Date: Sun, 29 Jun 2003 22:38:44 -0400
Subject: [Python-Dev] Meaty debugging mystery
Message-ID: <LNBBLJKPBEHFEDALKOLCCEGJEMAB.tim.one@comcast.net>

Neil Schemenauer was running regrtest with -r and got a segfault.  He
whittled it down to running just

    -u bsddb test_logging test_bsddb3

This was confirmed on Win2K, Win98, and some version of Linux.  He also
discovered that the problem went away if test_logging.py's

    locale.setlocale(locale.LC_ALL, '')

was commented out.

I've since found that the problem persists if

+ All the suite.addTest() calls in bsddb/test/test_basics.py are
  commented out except for

    suite.addTest(unittest.makeSuite(BTreeMultiDBTestCase))

and

+ All the entries in test_bsddb3.py's test_modules list are commented
  out except for

        'test_basics',

Then running yields this output:

test_bsddb3
test01_GetsAndPuts (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok
test02_DictionaryMethods (bsddb.test.test_basics.BTreeMultiDBTestCase) ...
ok
test03_SimpleCursorStuff (bsddb.test.test_basics.BTreeMultiDBTestCase) ...
ok
test04_PartialGetAndPut (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok
test05_GetSize (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok
test06_Truncate (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok
test09_MultiDB (bsddb.test.test_basics.BTreeMultiDBTestCase) ... FAIL

and that's when the crash happens.

I don't have time to dig into this more.  Looks like a good one, though!



From martin@v.loewis.de  Mon Jun 30 07:11:17 2003
From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=)
Date: 30 Jun 2003 08:11:17 +0200
Subject: [Python-Dev] Meaty debugging mystery
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEGJEMAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCCEGJEMAB.tim.one@comcast.net>
Message-ID: <m38yrkumbe.fsf@mira.informatik.hu-berlin.de>

Tim Peters <tim.one@comcast.net> writes:

> I don't have time to dig into this more.  Looks like a good one, though!

A quick glance shows it is a heap corruption:

#0  0xdbdbdbdb in ?? ()
#1  0x40977c40 in __bam_c_close (dbc=0x826c058, root_pgno=0, rmroot=0x2) at ../btree/bt_cursor.c:601
#2  0x40997f37 in __db_c_close (dbc=0x826c058) at ../db/db_cam.c:135
#3  0x4054e1e3 in DBCursor_dealloc (self=0x40258d20) at /home/martin/work/py2.3/Modules/_bsddb.c:771
#4  0x080817a7 in _Py_Dealloc (op=0x40258d20) at Objects/object.c:2022
#5  0x08104e32 in frame_dealloc (f=0x826b26c) at Objects/frameobject.c:394
#6  0x080817a7 in _Py_Dealloc (op=0x826b26c) at Objects/object.c:2022
#7  0x080e65d8 in tb_dealloc (tb=0x40a57b34) at Python/traceback.c:41
#8  0x080817a7 in _Py_Dealloc (op=0x40a57b34) at Objects/object.c:2022
#9  0x080e6581 in tb_dealloc (tb=0x40a579f4) at Python/traceback.c:40
#10 0x080817a7 in _Py_Dealloc (op=0x40a579f4) at Objects/object.c:2022
#11 0x08079eaf in insertdict (mp=0x40245854, key=0x40394c28, hash=1492466088, value=0x40a6fc34)
    at Objects/dictobject.c:379
#12 0x0807a3d7 in PyDict_SetItem (op=0x40245854, key=0x40394c28, value=0x40a6fc34)
    at Objects/dictobject.c:533
#13 0x0807d710 in PyDict_SetItemString (v=0x40245854, key=0x8119310 "exc_traceback", item=0x40a6fc34)
    at Objects/dictobject.c:1976

It appears that dbc->dbp->dbenv has been freed already. Interestingly
enough, self->mydb->myenvobj->db_env is NULL, which means that
env.close() was called for it.

The specific test case triggering this problem is
test_basic.BasicMultiDBTestCase, apparently as the DBEnv is closed
before the cursor.

I'm uncertain how this could happen, as a DBEnv carries a db_ref
field, counting open databases.

Regards,
Martin



From simon@joyful.com  Sat Jun 28 08:45:53 2003
From: simon@joyful.com (Simon Michael)
Date: Sat, 28 Jun 2003 08:45:53 +0100
Subject: [Python-Dev] Re: doctest extensions
References: <3EC7D0E7.9000705@zope.com>
Message-ID: <87r85etzke.fsf@joyful.com>

Yes please! +1.

This makes me want to use doctests again (as does Terence Way's contracts
implementation).

Another issue for me is that all these big docstrings obscure my code.
Hmm.. if emacs could fold the tests and contracts parts, perhaps that
would be the answer.



From guido@python.org  Mon Jun 30 14:58:32 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 30 Jun 2003 09:58:32 -0400
Subject: [Python-Dev] RELEASED: Python 2.3b2
In-Reply-To: Your message of "29 Jun 2003 21:57:43 EDT."
 <1056938263.5689.25.camel@geddy>
References: <1056938263.5689.25.camel@geddy>
Message-ID: <200306301358.h5UDwWk25149@odiug.zope.com>

Thanks, Barry, for getting a release out on a Sunday, while I was
still recovering from a week of Belgian food, beer and hacking.  And
thanks also to Tim, Fred, Jeremy, Neil, and all others who helped
getting this release out.

Looking over the list of highlights it's clear that 2.3 is focusing on
stability.  I hope that we can limit trunk checkins to bugfixes only
between now and the final release of 2.3.

I can now mention why I suddenly wanted to accelerate 2.3's schedule.

At EuroPython I was cornered by the key Macpython developers with
exciting news: Apple's next release of Mac OSX, code-named Panther,
uses Python and Apple is planning to include Python 2.3 in that
release.  (Apple already ships Mac OSX with Python 2.2 included in the
developer tools, but Panther will actually use Python for some
essential functionality.)

Apple's schedule is such that August 1st is about the latest release
date for Python 2.3 that will make this possible.  I appreciate
everybody's help with keeping this schedule!

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


From just@letterror.com  Mon Jun 30 15:26:51 2003
From: just@letterror.com (Just van Rossum)
Date: Mon, 30 Jun 2003 16:26:51 +0200
Subject: [Python-Dev] RELEASED: Python 2.3b2
In-Reply-To: <200306301358.h5UDwWk25149@odiug.zope.com>
Message-ID: <r01050400-1026-F647EFA2AB0611D78EAF003065D5E7E4@[10.0.0.23]>

Guido van Rossum wrote:

> Thanks, Barry, for getting a release out on a Sunday, while I was
> still recovering from a week of Belgian food, beer and hacking. 

What was Belgian hacking like? ;-)

> And thanks also to Tim, Fred, Jeremy, Neil, and all others who helped
> getting this release out.

And thank *you* for adding the thread interruption C API we discussed at
EuroPython. Although I was looking forward to working with Alex on it, I
sure could use a Python-free evening when I got back; I'm sure Alex felt
the same way...

> (Apple already ships Mac OSX with Python 2.2 included in the
> developer tools,

(Nit: Python 2.2 is actually in the plain OSX 10.2 release, not in the
dev tools. In other words, *any* 10.2 user has Python installed.)

Just


From neal@metaslash.com  Mon Jun 30 15:35:22 2003
From: neal@metaslash.com (Neal Norwitz)
Date: Mon, 30 Jun 2003 10:35:22 -0400
Subject: [Python-Dev] 2.3b2 known bugs?
Message-ID: <20030630143521.GK1310@epoch.metaslash.com>

These are listed as known bugs in beta2 (pydotorg/2.3/bugs.ht), 
but I think they are solved:

 * On Solaris 8, build of the bz2 module failed for one correspondent;
   this may depend on the specific release or provisioning of the box.

 * The test for the logging module fails for some people on Solaris
   and Mac OS X.  A patch has been applied to CVS that hopefully fixes
   this.

Skip, I think you had both of these problems.  Is everything ok for you?

Neal


From walter@livinglogic.de  Mon Jun 30 15:57:44 2003
From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=)
Date: Mon, 30 Jun 2003 16:57:44 +0200
Subject: [Python-Dev] RELEASED: Python 2.3b2
In-Reply-To: <200306301358.h5UDwWk25149@odiug.zope.com>
References: <1056938263.5689.25.camel@geddy> <200306301358.h5UDwWk25149@odiug.zope.com>
Message-ID: <3F004FE8.3070004@livinglogic.de>

Guido van Rossum wrote:

> [...]
> 
> Looking over the list of highlights it's clear that 2.3 is focusing on
> stability.  I hope that we can limit trunk checkins to bugfixes only
> between now and the final release of 2.3.

Does this mean no new tests?

> [...]
> release.  (Apple already ships Mac OSX with Python 2.2 included in the
> developer tools, but Panther will actually use Python for some
> essential functionality.)

Can you tell us what functionality that is?

Bye,
    Walter Dörwald




From guido@python.org  Mon Jun 30 16:10:08 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 30 Jun 2003 11:10:08 -0400
Subject: [Python-Dev] RELEASED: Python 2.3b2
In-Reply-To: Your message of "Mon, 30 Jun 2003 16:57:44 +0200."
 <3F004FE8.3070004@livinglogic.de>
References: <1056938263.5689.25.camel@geddy> <200306301358.h5UDwWk25149@odiug.zope.com>
 <3F004FE8.3070004@livinglogic.de>
Message-ID: <200306301510.h5UFA8w25615@odiug.zope.com>

> > Looking over the list of highlights it's clear that 2.3 is focusing on
> > stability.  I hope that we can limit trunk checkins to bugfixes only
> > between now and the final release of 2.3.
> 
> Does this mean no new tests?

Tests to test for fixed bugs are always okay, of course.

I would be conservative in rewriting tests -- only do this if it's
easy to see that the new test is equivalent to the old test.

> > [...]
> > release.  (Apple already ships Mac OSX with Python 2.2 included in the
> > developer tools, but Panther will actually use Python for some
> > essential functionality.)
> 
> Can you tell us what functionality that is?

All I know is that it has to do with PDF generation workflow.

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


From python@rcn.com  Mon Jun 30 16:11:06 2003
From: python@rcn.com (Raymond Hettinger)
Date: Mon, 30 Jun 2003 11:11:06 -0400
Subject: [Python-Dev] RELEASED: Python 2.3b2
References: <1056938263.5689.25.camel@geddy> <200306301358.h5UDwWk25149@odiug.zope.com> <3F004FE8.3070004@livinglogic.de>
Message-ID: <000f01c33f19$d4b57560$8e22a044@oemcomputer>

> Guido van Rossum wrote:
> 
> > [...]
> > 
> > Looking over the list of highlights it's clear that 2.3 is focusing on
> > stability.  I hope that we can limit trunk checkins to bugfixes only
> > between now and the final release of 2.3.
> 
> Does this mean no new tests?

If more test development can potentially expose bugs,
then that is a plus, but let's avoid creating suites that
are their own can of worms (like test_logging).

Also, new tests should continue to go in for each bugfix
(to make sure it works for everyone and stays working).


Raymond Hettinger


From pinard@iro.umontreal.ca  Mon Jun 30 17:03:54 2003
From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois_Pinard?=)
Date: 30 Jun 2003 12:03:54 -0400
Subject: [Python-Dev] Delayed `-i'! :-)
Message-ID: <oqsmprft79.fsf@titan.progiciels-bpi.ca>

[Fran=E7ois Pinard, 2003-06-26]

> Hi, Python friends.
>=20
> Is there a way for a script to activate the effect of the `-i' option,
> that is, to force interactive mode once `__main__' has run? [...]

Thanks.  Setting PYTHONINSPECT solves this matter in 2.3b2, Linux and Windo=
ws.

--=20
Fran=C3=A7ois Pinard   http://www.iro.umontreal.ca/~pinard

--=20
Fran=C3=A7ois Pinard   http://www.iro.umontreal.ca/~pinard


From skip@pobox.com  Mon Jun 30 18:45:37 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 30 Jun 2003 12:45:37 -0500
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
Message-ID: <16128.30529.80713.425528@montanaro.dyndns.org>

Was the 2.3b2 tarfile generated in such a way that it requires GNU tar?  I'm
unable to extract it on a Solaris 8 system using /usr/bin/tar.  It gunzips
fine and I can extract it on my Mac OS X system, but on Solaris I get, "tar:
directory checksum error" and fine a truncated directory tree.  I've also
verified that the files downloaded to the Mac and the Solaris box have the
same checksum.

Skip


From barry@python.org  Mon Jun 30 19:07:18 2003
From: barry@python.org (Barry Warsaw)
Date: 30 Jun 2003 14:07:18 -0400
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <16128.30529.80713.425528@montanaro.dyndns.org>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
Message-ID: <1056996438.2286.32.camel@yyz>

On Mon, 2003-06-30 at 13:45, Skip Montanaro wrote:
> Was the 2.3b2 tarfile generated in such a way that it requires GNU tar?  I'm
> unable to extract it on a Solaris 8 system using /usr/bin/tar.  It gunzips
> fine and I can extract it on my Mac OS X system, but on Solaris I get, "tar:
> directory checksum error" and fine a truncated directory tree.  I've also
> verified that the files downloaded to the Mac and the Solaris box have the
> same checksum.

I generated the tarball using the PEP 101 suggestion, which is the same
way I generated the 2.2.3 tarball:

tar cf - Python-2.3b2 | gzip -9 > Python-2.3b2.tgz

so it's possible there are GNU tar-isms in the file (I don't have access
to a non-GNU tar).  

Did you have a problem with the 2.2.3 tarball?  I haven't seen any other
reports of problems with either.

-Barry




From skip@pobox.com  Mon Jun 30 19:45:15 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 30 Jun 2003 13:45:15 -0500
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <1056996438.2286.32.camel@yyz>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
Message-ID: <16128.34107.69805.436131@montanaro.dyndns.org>

    >> Was the 2.3b2 tarfile generated in such a way that it requires GNU
    >> tar?

    Barry> I generated the tarball using the PEP 101 suggestion, which is
    Barry> the same way I generated the 2.2.3 tarball:

    Barry> tar cf - Python-2.3b2 | gzip -9 > Python-2.3b2.tgz

    Barry> so it's possible there are GNU tar-isms in the file (I don't have
    Barry> access to a non-GNU tar).

I just tried creating a tarfile on my Mac using "tar cfoO".  The -o and -O
flags are described as

     -O            Write old-style (non-POSIX) archives.

     -o            Don't write directory information that the older (V7) style
                   tar is unable to decode.  This implies the -O flag.

I still got a directory checksum error.  Next step was to try extracting the
tarfile (that generated with -o and -O) on another Solaris 8 system.  That
worked fine, so I will assume the problem is on the first machine I tried.

Skip



From barry@python.org  Mon Jun 30 19:57:56 2003
From: barry@python.org (Barry Warsaw)
Date: 30 Jun 2003 14:57:56 -0400
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <16128.34107.69805.436131@montanaro.dyndns.org>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
Message-ID: <1056999476.2286.39.camel@yyz>

On Mon, 2003-06-30 at 14:45, Skip Montanaro wrote:
>  
> I still got a directory checksum error.  Next step was to try extracting the
> tarfile (that generated with -o and -O) on another Solaris 8 system.  That
> worked fine, so I will assume the problem is on the first machine I tried.

Are you sure you weren't somehow using GNU tar on the second machine?

-Barry




From skip@pobox.com  Mon Jun 30 20:48:20 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 30 Jun 2003 14:48:20 -0500
Subject: [Python-Dev] 2.3b2 known bugs?
In-Reply-To: <20030630143521.GK1310@epoch.metaslash.com>
References: <20030630143521.GK1310@epoch.metaslash.com>
Message-ID: <16128.37892.532325.746846@montanaro.dyndns.org>

    Neal>  * On Solaris 8, build of the bz2 module failed for one
    Neal>    correspondent; this may depend on the specific release or
    Neal>    provisioning of the box.

    Neal>  * The test for the logging module fails for some people on
    Neal>    Solaris and Mac OS X.  A patch has been applied to CVS that
    Neal>    hopefully fixes this.

    Neal> Skip, I think you had both of these problems.  Is everything ok
    Neal> for you?

Maybe I'm just suffering from bit rot caused by old age, but I didn't
recognize either item.  I located the bz2 problem in the archives.  After a
fair bit of fiddling, I got 2.3b2 installed and built on Solaris 8.  "make
test" showed this output at the end:

    225 tests OK.
    29 tests skipped:
        test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl
        test_curses test_email_codecs test_gdbm test_gl test_imgfile
        test_linuxaudiodev test_macfs test_macostools test_mpz test_nis
        test_normalization test_ossaudiodev test_pep277 test_plistlib
        test_scriptpackages test_socket_ssl test_socketserver
        test_sunaudiodev test_timeout test_unicode_file test_urllibnet
        test_winreg test_winsound
    2 skips unexpected on sunos5:
        test_sunaudiodev test_nis

and running those two tests alone works:

    $ ./python Lib/test/regrtest.py test_bz2 test_logging
    test_bz2
    test_logging
    All 2 tests OK.

so I guess the logging and bz2 problems are kaput.

Skip


From skip@pobox.com  Mon Jun 30 20:54:23 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 30 Jun 2003 14:54:23 -0500
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <16128.34107.69805.436131@montanaro.dyndns.org>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
Message-ID: <16128.38255.852223.80699@montanaro.dyndns.org>

    Skip> Next step was to try extracting the tarfile (that generated with
    Skip> -o and -O) on another Solaris 8 system.  That worked fine, so I
    Skip> will assume the problem is on the first machine I tried.

Belay that.  The other machine had GNU tar in /usr/local/bin...  With
/usr/bin/tar I get the same problem.

Off-list John Abel suggested perhaps it might be a path length problem.  I
was more concerned about filenames containing spaces or non-ASCII characters
but didn't find any smoking guns.  Looking at the characters in the
filenames, I didn't see any files whose name wasn't matched by this regular
expression:

    [-:A-Za-z.0-9 _()]+

In addition to several files containing spaces, there is a directory
component named "(vise)" which seems a bit odd, but which should be okay for
tar.

Next check was on the length of things as John had suggested.  The longest
component is only 110 characters:

    ./Mac/OSXResources/app/Resources/English.lproj/Documentation/macpython_ide_tutorial/entering_in_new_window.gif

but is in the directory where tar craps out.  I then generated another
tarfile which excluded just the .../macpython_ide_tutorial directory.  That
extracts fine:

    bash-2.03$ /usr/bin/tar xf ../tmp/Py2.3.tar 
    bash-2.03$ 

Just or Jack, is there any chance we can rearrange the Mac subtree to
shorten up that long path?  I don't know if it's the number of directory
components or the total length of the path that's causing the problem.

In the meantime, perhaps it's worth noting on the website that extracting
the tarfile on some platforms may fail.

Skip


From barry@python.org  Mon Jun 30 21:02:52 2003
From: barry@python.org (Barry Warsaw)
Date: 30 Jun 2003 16:02:52 -0400
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <16128.38255.852223.80699@montanaro.dyndns.org>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
 <16128.38255.852223.80699@montanaro.dyndns.org>
Message-ID: <1057003372.2286.55.camel@yyz>

On Mon, 2003-06-30 at 15:54, Skip Montanaro wrote:

> In the meantime, perhaps it's worth noting on the website that extracting
> the tarfile on some platforms may fail.

I've updated the bugs page to remove the kaput bugs and add a note about
extraction problems on Solaris 8.

-Barry




From skip@pobox.com  Mon Jun 30 21:10:05 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 30 Jun 2003 15:10:05 -0500
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <1057003372.2286.55.camel@yyz>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
 <16128.38255.852223.80699@montanaro.dyndns.org>
 <1057003372.2286.55.camel@yyz>
Message-ID: <16128.39197.430829.394958@montanaro.dyndns.org>

    Barry> I've updated the bugs page to remove the kaput bugs and add a
    Barry> note about extraction problems on Solaris 8.

Thanks.  I found this item on the Haskell website:

    http://www.haskell.org/pipermail/hugs-bugs/2002-November/001045.html

Looks like Solaris (<= 8) tar has a pathname limit of 80 characters.  Should
we try and squeeze the Python directory tree into that limit or simply tell
people to use GNU tar if their tar barfs?

Skip




From jepler@unpythonic.net  Mon Jun 30 21:15:11 2003
From: jepler@unpythonic.net (Jeff Epler)
Date: Mon, 30 Jun 2003 15:15:11 -0500
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <16128.39197.430829.394958@montanaro.dyndns.org>
References: <16128.30529.80713.425528@montanaro.dyndns.org> <1056996438.2286.32.camel@yyz> <16128.34107.69805.436131@montanaro.dyndns.org> <16128.38255.852223.80699@montanaro.dyndns.org> <1057003372.2286.55.camel@yyz> <16128.39197.430829.394958@montanaro.dyndns.org>
Message-ID: <20030630201510.GB14975@unpythonic.net>

On Mon, Jun 30, 2003 at 03:10:05PM -0500, Skip Montanaro wrote:
> 
>     Barry> I've updated the bugs page to remove the kaput bugs and add a
>     Barry> note about extraction problems on Solaris 8.
> 
> Thanks.  I found this item on the Haskell website:
> 
>     http://www.haskell.org/pipermail/hugs-bugs/2002-November/001045.html
> 
> Looks like Solaris (<= 8) tar has a pathname limit of 80 characters.  Should
> we try and squeeze the Python directory tree into that limit or simply tell
> people to use GNU tar if their tar barfs?
> 
> Skip

... provide a "macless" tarball for problem systems, and enforce an 80
char limit on it?

is this a traditional tar or Solaris tar limitation?  It's not clear,
having RTFA'd.  It sounds like the 80-char limit is Solaris, and the
100-char limit is traditional?

Jeff


From barry@python.org  Mon Jun 30 21:21:11 2003
From: barry@python.org (Barry Warsaw)
Date: 30 Jun 2003 16:21:11 -0400
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <16128.39197.430829.394958@montanaro.dyndns.org>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
 <16128.38255.852223.80699@montanaro.dyndns.org>
 <1057003372.2286.55.camel@yyz>
 <16128.39197.430829.394958@montanaro.dyndns.org>
Message-ID: <1057004471.2794.3.camel@yyz>

On Mon, 2003-06-30 at 16:10, Skip Montanaro wrote:
>     Barry> I've updated the bugs page to remove the kaput bugs and add a
>     Barry> note about extraction problems on Solaris 8.
> 
> Thanks.  I found this item on the Haskell website:
> 
>     http://www.haskell.org/pipermail/hugs-bugs/2002-November/001045.html
> 
> Looks like Solaris (<= 8) tar has a pathname limit of 80 characters.  Should
> we try and squeeze the Python directory tree into that limit or simply tell
> people to use GNU tar if their tar barfs?

If Jack can reasonably squeeze the pathnames under this limit than
that's fine, otherwise I would point people toward GNU tar as the
solution (unless someone else is motivated to generate Solaris-friendly
tarballs).

-Barry




From skip@pobox.com  Mon Jun 30 21:22:11 2003
From: skip@pobox.com (Skip Montanaro)
Date: Mon, 30 Jun 2003 15:22:11 -0500
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <20030630201510.GB14975@unpythonic.net>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
 <16128.38255.852223.80699@montanaro.dyndns.org>
 <1057003372.2286.55.camel@yyz>
 <16128.39197.430829.394958@montanaro.dyndns.org>
 <20030630201510.GB14975@unpythonic.net>
Message-ID: <16128.39923.526110.174847@montanaro.dyndns.org>

    Jeff> ... provide a "macless" tarball for problem systems, and enforce
    Jeff> an 80 char limit on it?

I think that would be troublesome.  Some people would pick up the wrong
tarball, and it would require extra work on the part of whoever creates a
distribution tarball.

    Jeff> is this a traditional tar or Solaris tar limitation?  It's not
    Jeff> clear, having RTFA'd.  It sounds like the 80-char limit is
    Jeff> Solaris, and the 100-char limit is traditional?

I'm game for just recommending people get GNU tar, but it's available on all
the platforms I care about.  Other people may not be so fortunate.

Skip



From jepler@unpythonic.net  Mon Jun 30 21:31:32 2003
From: jepler@unpythonic.net (Jeff Epler)
Date: Mon, 30 Jun 2003 15:31:32 -0500
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: <16128.39923.526110.174847@montanaro.dyndns.org>
References: <16128.30529.80713.425528@montanaro.dyndns.org> <1056996438.2286.32.camel@yyz> <16128.34107.69805.436131@montanaro.dyndns.org> <16128.38255.852223.80699@montanaro.dyndns.org> <1057003372.2286.55.camel@yyz> <16128.39197.430829.394958@montanaro.dyndns.org> <20030630201510.GB14975@unpythonic.net> <16128.39923.526110.174847@montanaro.dyndns.org>
Message-ID: <20030630203132.GC14975@unpythonic.net>

On Mon, Jun 30, 2003 at 03:22:11PM -0500, Skip Montanaro wrote:
> I'm game for just recommending people get GNU tar, but it's available on all
> the platforms I care about.  Other people may not be so fortunate.

Me, too.  I think even on the more godforesaken platforms I use (hpux8)
I could compile gnu tar.

Jeff


From ben@dadsetan.com  Mon Jun 30 22:48:45 2003
From: ben@dadsetan.com (Behrang Dadsetan)
Date: Mon, 30 Jun 2003 22:48:45 +0100
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
References: <16128.30529.80713.425528@montanaro.dyndns.org> <1056996438.2286.32.camel@yyz> <16128.34107.69805.436131@montanaro.dyndns.org> <16128.38255.852223.80699@montanaro.dyndns.org> <1057003372.2286.55.camel@yyz> <16128.39197.430829.394958@montanaro.dyndns.org> <20030630201510.GB14975@unpythonic.net> <16128.39923.526110.174847@montanaro.dyndns.org> <20030630203132.GC14975@unpythonic.net>
Message-ID: <3F00B03D.6030209@dadsetan.com>

As a very wild guess I would say any platform where python could 
compile, GNU tar will compile as well

Of course if you would like to allow people not being able to compile 
python to still view its code, ... :)

Ben.

Jeff Epler wrote:

>On Mon, Jun 30, 2003 at 03:22:11PM -0500, Skip Montanaro wrote:
>  
>
>>I'm game for just recommending people get GNU tar, but it's available on all
>>the platforms I care about.  Other people may not be so fortunate.
>>    
>>
>
>Me, too.  I think even on the more godforesaken platforms I use (hpux8)
>I could compile gnu tar.
>
>Jeff
>
>_______________________________________________
>Python-Dev mailing list
>Python-Dev@python.org
>http://mail.python.org/mailman/listinfo/python-dev
>
>  
>




From pinard@iro.umontreal.ca  Mon Jun 30 21:59:16 2003
From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois_Pinard?=)
Date: 30 Jun 2003 16:59:16 -0400
Subject: [Python-Dev] Re: Problem with 2.3b2 tarfile?
In-Reply-To: <1057004471.2794.3.camel@yyz>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
 <16128.38255.852223.80699@montanaro.dyndns.org>
 <1057003372.2286.55.camel@yyz>
 <16128.39197.430829.394958@montanaro.dyndns.org>
 <1057004471.2794.3.camel@yyz>
Message-ID: <oq7k73ffiz.fsf@titan.progiciels-bpi.ca>

[Barry Warsaw]

> (unless someone else is motivated to generate Solaris-friendly tarballs).

Thinking loud.  I remember that GNU `tar' already has a few ugly hacks to
inter-operate despite serious glitches (or blunt bugs) in Sun and Solaris
`tar's.  Moreover, the last maintainer of `tar' was very fond of Solaris.

P.S. - I often objected that there are so many `Solarisms' in GNU.  I was
somewhat pitiful for users of old hardware, from deceased companies.  Before
Linux existed, such users clearly did not have the monetary means to do
better.  But Sun?  They, rather than us, should support their users... :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard


From pinard@iro.umontreal.ca  Mon Jun 30 22:19:12 2003
From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois_Pinard?=)
Date: 30 Jun 2003 17:19:12 -0400
Subject: [Python-Dev] Re: Problem with 2.3b2 tarfile?
In-Reply-To: <20030630201510.GB14975@unpythonic.net>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
 <16128.38255.852223.80699@montanaro.dyndns.org>
 <1057003372.2286.55.camel@yyz>
 <16128.39197.430829.394958@montanaro.dyndns.org>
 <20030630201510.GB14975@unpythonic.net>
Message-ID: <oq3chrfelr.fsf@titan.progiciels-bpi.ca>

[Jeff Epler]

> the 100-char limit is traditional?

Traditional.  POSIX extends the limit somewhat, but the rules are very
strange.  There are two separated fields in the header, and whenever the
second field is non-empty, a slash is to be _implied_ between both, so you
cannot cut the path string anywhere.

One source of incompatibility from GNU tar came from the fact the FSF staff
used that second field to hold binary information for GNU extensions, like
for sparse files information.  To go over 100 characters, GNU tar used its
own ways.  I remember that while studying these problems in deep detail, I
was dismayed to see than when GNU extensions were added, the guys who did it
already had a copy of the POSIX draft (it was only a draft then), in which
the intent of actually using the second field, was clearly stated.

In any case, I devised a long and careful migration plan (accepted by RMS at
the time) for better POSIX-ifying GNU tar, but I fear this plan has been
abandoned with the change of maintainer.  If I remember correctly, GNU tar
is more or less able to decipher POSIX archives, but you should not rely on
it for generating them in some unusual conditions, like when file names are
long.  But I may be all wrong, as I did not follow recent changes.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard


From pinard@iro.umontreal.ca  Mon Jun 30 22:46:31 2003
From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois_Pinard?=)
Date: 30 Jun 2003 17:46:31 -0400
Subject: [Python-Dev] Re: Problem with 2.3b2 tarfile?
In-Reply-To: <3F00B03D.6030209@dadsetan.com>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
 <16128.38255.852223.80699@montanaro.dyndns.org>
 <1057003372.2286.55.camel@yyz>
 <16128.39197.430829.394958@montanaro.dyndns.org>
 <20030630201510.GB14975@unpythonic.net>
 <16128.39923.526110.174847@montanaro.dyndns.org>
 <20030630203132.GC14975@unpythonic.net>
 <3F00B03D.6030209@dadsetan.com>
Message-ID: <oqy8zjdyrs.fsf@titan.progiciels-bpi.ca>

[Behrang Dadsetan]

> As a very wild guess I would say any platform where python could compile,
> GNU tar will compile as well

A last message about this. :-)

The ideal is to create POSIX archives.  GNU `tar' is reasonably conforming
when unpacking an archive, is often conforming when creating a new one, but
not necessarily.  When it errs, it errs _big_.  Sun `tar' attempts to be
POSIX conforming, and may be more POSIX conforming on the average of all
aspects.  However, whenever they goof, they usually try to stay compatible
with their previous mistakes for the sake of their own users.

The most known example is how to compute the header checksum (there are
other examples and issues, I'm just taking the most known to illustrate how
the history goes).  When Sun recompiled Unix `tar' from sources, they missed
that their machines were not signing chars the same way, but of course, they
were able to read the archives they were creating.  Later, `HP-UX' purposely
made the same error "for being compatible with Sun".  POSIX defined the
checksum according to the original and documented design, making Sun and
HP-UX officially wrong.  On reading an archive, GNU `tar' computes two
checksums, one the POSIX way, the other the Sun way, and ensures (at least)
one of them matches.  On creation, GNU `tar' uses the POSIX checksum.  The
discrepancy only shows if there is some character with the high bit set.
Sun might be computing two checksum as well, nowadays.

Declaring that Solaris is right, or GNU `tar' is right, is not the best way
to ponder all this.  The end line is they are all wrong, even GNU `tar' has
its good share of horrors.  A reasonable way to go is that we all attempt to
follow POSIX standards, whether we like them or not, however strange they
may be.  In this way, there is some chance that we converge, instead of
fighting like cats in the backyard.  Unless you take the bet that GNU `tar'
will squash them all?  It will happen if Linux takes over the world! :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard


From rowen@cesmail.net  Mon Jun 30 22:46:58 2003
From: rowen@cesmail.net (Russell E. Owen)
Date: Mon, 30 Jun 2003 14:46:58 -0700
Subject: [Python-Dev] Re: RELEASED: Python 2.3b2
References: <1056938263.5689.25.camel@geddy> <200306301358.h5UDwWk25149@odiug.zope.com>
Message-ID: <rowen-32B5CF.14465830062003@main.gmane.org>

In article <200306301358.h5UDwWk25149@odiug.zope.com>,
 Guido van Rossum <guido@python.org> wrote:

> At EuroPython I was cornered by the key Macpython developers with
> exciting news: Apple's next release of Mac OSX, code-named Panther,
> uses Python and Apple is planning to include Python 2.3 in that
> release....

Wonderful news! I am excited that you're willing to try to get 2.3 out 
in time for Panther.

Python 2.3 is a tremendous improvement over the unix Python 2.2. 
included with macOS X 10.2. \r line endings in source code OK, framework 
build, plays well with Tkinter and wxPython, included IDE...frabjous day!

-- Russell



From barry@python.org  Mon Jun 30 22:53:04 2003
From: barry@python.org (Barry Warsaw)
Date: 30 Jun 2003 17:53:04 -0400
Subject: [Python-Dev] Re: Problem with 2.3b2 tarfile?
In-Reply-To: <oqy8zjdyrs.fsf@titan.progiciels-bpi.ca>
References: <16128.30529.80713.425528@montanaro.dyndns.org>
 <1056996438.2286.32.camel@yyz>
 <16128.34107.69805.436131@montanaro.dyndns.org>
 <16128.38255.852223.80699@montanaro.dyndns.org>
 <1057003372.2286.55.camel@yyz>
 <16128.39197.430829.394958@montanaro.dyndns.org>
 <20030630201510.GB14975@unpythonic.net>
 <16128.39923.526110.174847@montanaro.dyndns.org>
 <20030630203132.GC14975@unpythonic.net> <3F00B03D.6030209@dadsetan.com>
 <oqy8zjdyrs.fsf@titan.progiciels-bpi.ca>
Message-ID: <1057009984.2794.12.camel@yyz>

On Mon, 2003-06-30 at 17:46, Fran=E7ois Pinard wrote:

> fighting like cats in the backyard.  Unless you take the bet that GNU `=
tar'
> will squash them all?  It will happen if Linux takes over the world! :-=
)

Remind me what Solaris is again <wink>.
-Barry




From guido@python.org  Mon Jun 30 22:55:44 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 30 Jun 2003 17:55:44 -0400
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: Your message of "Mon, 30 Jun 2003 14:54:23 CDT."
 <16128.38255.852223.80699@montanaro.dyndns.org>
References: <16128.30529.80713.425528@montanaro.dyndns.org> <1056996438.2286.32.camel@yyz> <16128.34107.69805.436131@montanaro.dyndns.org>
 <16128.38255.852223.80699@montanaro.dyndns.org>
Message-ID: <200306302155.h5ULtiB27403@odiug.zope.com>

> Next check was on the length of things as John had suggested.  The longest
> component is only 110 characters:
> 
>     ./Mac/OSXResources/app/Resources/English.lproj/Documentation/macpython_ide_tutorial/entering_in_new_window.gif

This is the culprit.  In a "classic" tar file, a filename can be only
100 characters.  (See Lib/tarfile.py. :-)

> Just or Jack, is there any chance we can rearrange the Mac subtree to
> shorten up that long path?  I don't know if it's the number of directory
> components or the total length of the path that's causing the problem.

The total length must be <= 100.

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


From guido@python.org  Mon Jun 30 22:57:47 2003
From: guido@python.org (Guido van Rossum)
Date: Mon, 30 Jun 2003 17:57:47 -0400
Subject: [Python-Dev] Problem with 2.3b2 tarfile?
In-Reply-To: Your message of "Mon, 30 Jun 2003 15:15:11 CDT."
 <20030630201510.GB14975@unpythonic.net>
References: <16128.30529.80713.425528@montanaro.dyndns.org> <1056996438.2286.32.camel@yyz> <16128.34107.69805.436131@montanaro.dyndns.org> <16128.38255.852223.80699@montanaro.dyndns.org> <1057003372.2286.55.camel@yyz> <16128.39197.430829.394958@montanaro.dyndns.org>
 <20030630201510.GB14975@unpythonic.net>
Message-ID: <200306302157.h5ULvlI27432@odiug.zope.com>

> > Thanks.  I found this item on the Haskell website:
> > 
> >     http://www.haskell.org/pipermail/hugs-bugs/2002-November/001045.html
> > 
> > Looks like Solaris (<= 8) tar has a pathname limit of 80
> > characters.  Should we try and squeeze the Python directory tree
> > into that limit or simply tell people to use GNU tar if their tar
> > barfs?
> > 
> > Skip
> 
> ... provide a "macless" tarball for problem systems, and enforce an 80
> char limit on it?
> 
> is this a traditional tar or Solaris tar limitation?  It's not clear,
> having RTFA'd.  It sounds like the 80-char limit is Solaris, and the
> 100-char limit is traditional?

The 80 is a misreading of that Haskell message.  There is only a 100
char limit.  (The message just explains that the shortest name
remaining is 80, which is less than 100.)

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


From drifty@alum.berkeley.edu  Mon Jun 30 23:56:37 2003
From: drifty@alum.berkeley.edu (Brett C.)
Date: Mon, 30 Jun 2003 15:56:37 -0700
Subject: [Python-Dev] test_strptime failed
In-Reply-To: <1056732884.25964.4.camel@slothrop.zope.com>
References: <1054850175.24597.27.camel@slothrop.zope.com>	 <3EE8FDAE.30605@ocf.berkeley.edu> <1056732884.25964.4.camel@slothrop.zope.com>
Message-ID: <3F00C025.4030007@ocf.berkeley.edu>

Jeremy Hylton wrote:
> On Thu, 2003-06-12 at 18:24, Brett C. wrote:
> 
>>>test test_strptime failed -- Traceback (most recent call last):
>>>  File "/home/jeremy/src/python/dist/src/Lib/test/test_strptime.py",
>>>line 203, in test_compile
>>>    self.failUnless(found, "Matching failed on '%s' using '%s' regex" %
>>>  File "/home/jeremy/src/python/dist/src/Lib/unittest.py", line 268, in
>>>failUnless
>>>    if not expr: raise self.failureException, msg
>>>AssertionError: Matching failed on 'Thu 05 Jun 2003 05:46:43 PM EDT'
>>>using
>>>'(?P<a>Mon|Tue|Wed|Thu|Fri|Sat|Sun)\s*(?P<d>3[0-1]|[1-2]\d|0[1-9]|[1-9]|
>>>[1-9])\s*(?P<b>Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s*(?P<Y>\d\d\d\d)\s*(?P<I>1[0-2]|0[1-9]|[1-9]):(?P<M>[0-5]\d|\d):(?P<S>6[0-1]|[0-5]\d|\d)\s*(?P<p>AM|PM)\s*EST' regex
>>>
>>
>>Jeremy, are you still getting this failure?  How about anyone else?
> 
> 
> Strangely enough, I am.  I've run the tests irregularly over the last
> couple of weeks without seeing it.  But today I ran the tests and say
> the failure.
> 
> Is there any reason you expect that this is a transient bug?
> 

Timezone info is fetched from time.tzname so it should be consistent but 
can change between platforms.

Below is from an email I sent a while back.  Can you try what I suggest 
and let me know the results?


 > Until then, Jeremy, can you see if it passes if you back out the 
recent changes that modified timezone handling (I think it was just the 
last one; added GMT and UTC acknowledgement as well as handilng the 
timezone better, or so I thought)?


So it is actually two versions ago; version 1.16 is what I would like 
you to run (1.17 tried to make timzone handling more robust and 1.18 
calls time.tzset in case there was a locale change since time.tzname 
does not get changed without the call).  Can you also run the below line 
of code and paste in what gets spit out?::

     >>> import time, _strptime; time.daylight; time.tzname; 
_strptime.LocaleTime().timezone; time.daylight; time.tzname; time.tzset()

-Brett